Improve context loss error handling

Improve context loss error handling

This patch implements interaction with KHR_robustness. It's especially
concerned with handling CONTEXT_LOST_KHR errors: as soon as one is
encountered, the normal context loss handling code is triggered, with
the addition that context guilt information is queried from GL. The patch
fixes asserts caused by CONTEXT_LOST_KHR errors in debug mode, which
should help with further development, and hides CONTEXT_LOST_KHR errors
from command buffer clients which are not supposed to see them.

For plumbing, bindings are added for the KHR_robustness API entry points,
and command buffer autogenerated files are updated so that
GLES2Util::GetStringEnum works with CONTEXT_LOST_KHR.

Redundant LoseContext call that was called on the context after
LoseContext was already called on the whole context group is removed from
GLES2CommandDecoderImpl::OnOutOfMemoryError. The behavior that the guilty
context is unknown when an out of memory error is generated is kept, as
it does not make sense to point the finger at a specific context on an
when it is not known which context was actually consuming the most
memory.

BUG=428332
Committed: https://crrev.com/37cc50e7e5f15299040d1b535929d0212aa06b9a
Cr-Commit-Position: refs/heads/master@{#302249}

[oetuaho-nv, 2014-10-29 14:56:15]

oetuaho@nvidia.com changed reviewers:
+ bajones@chromium.org, sievers@chromium.org, zmo@chromium.org

[oetuaho-nv, 2014-10-29 14:56:16]

Please review. There are still problems in this area after this patch, including
lack of automated testing, but this patch will at least fix problems concerning
KHR_robustness specifically.

[Zhenyao Mo, 2014-10-29 17:46:31]

zmo@chromium.org changed reviewers:
+ kbr@chromium.org

[Zhenyao Mo, 2014-10-29 17:46:31]

Mostly look good.  Also add kbr.

https://codereview.chromium.org/689633003/diff/1/gpu/command_buffer/common/gl...
File gpu/command_buffer/common/gles2_cmd_utils_implementation_autogen.h (right):

https://codereview.chromium.org/689633003/diff/1/gpu/command_buffer/common/gl...
gpu/command_buffer/common/gles2_cmd_utils_implementation_autogen.h:16: 0x9260,
Most changes in this file is unrelated.

I suggest you create a separate CL that simply call
gpu/command_buffer/build_gles2_cmd_buffer.py.

Then this CL will be cleaner.

Sorry about the mess that's left before you.

[Ken Russell (switch to Gerrit), 2014-10-29 22:21:21]

lgtm

https://codereview.chromium.org/689633003/diff/1/gpu/command_buffer/common/gl...
File gpu/command_buffer/common/gles2_cmd_utils_implementation_autogen.h (right):

https://codereview.chromium.org/689633003/diff/1/gpu/command_buffer/common/gl...
gpu/command_buffer/common/gles2_cmd_utils_implementation_autogen.h:16: 0x9260,
On 2014/10/29 17:46:31, Zhenyao Mo wrote:
> Most changes in this file is unrelated.
> 
> I suggest you create a separate CL that simply call
> gpu/command_buffer/build_gles2_cmd_buffer.py.
> 
> Then this CL will be cleaner.
> 
> Sorry about the mess that's left before you.

Or is it the case that the order of entries in this file is essentially random?

https://codereview.chromium.org/689633003/diff/1/ui/gl/gl_gl_api_implementati...
File ui/gl/gl_gl_api_implementation.cc (right):

https://codereview.chromium.org/689633003/diff/1/ui/gl/gl_gl_api_implementati...
ui/gl/gl_gl_api_implementation.cc:445: #if !defined(NDEBUG)
Please use #if DCHECK_IS_ON instead. Our Release mode bots use
dcheck_always_on=1.

[no sievers, 2014-10-29 23:35:33]

lgtm with the other's comments addressed.

https://codereview.chromium.org/689633003/diff/1/gpu/command_buffer/service/g...
File gpu/command_buffer/service/gles2_cmd_decoder.cc (right):

https://codereview.chromium.org/689633003/diff/1/gpu/command_buffer/service/g...
gpu/command_buffer/service/gles2_cmd_decoder.cc:9741: //
TODO(oetuaho@nvidia.com): This is not correct in virtual context mode.
Should we just always say UNKNOWN with virtual contexts since it doesn't really
make sense to talk about which context is guilty then?

You could check
group()->feature_info()->workarounds().use_virtualized_gl_contexts here.

[oetuaho-nv, 2014-10-30 09:17:15]

I split the changes to autogenerated files to this patch:
https://codereview.chromium.org/690753005/

I'll update this one after that one is merged.

https://codereview.chromium.org/689633003/diff/1/gpu/command_buffer/common/gl...
File gpu/command_buffer/common/gles2_cmd_utils_implementation_autogen.h (right):

https://codereview.chromium.org/689633003/diff/1/gpu/command_buffer/common/gl...
gpu/command_buffer/common/gles2_cmd_utils_implementation_autogen.h:16: 0x9260,
On 2014/10/29 22:21:21, Ken Russell wrote:
> On 2014/10/29 17:46:31, Zhenyao Mo wrote:
> > Most changes in this file is unrelated.
> > 
> > I suggest you create a separate CL that simply call
> > gpu/command_buffer/build_gles2_cmd_buffer.py.
> > 
> > Then this CL will be cleaner.
> > 
> > Sorry about the mess that's left before you.
> 
> Or is it the case that the order of entries in this file is essentially
random?

I didn't intentionally change the order. It seems like WriteCommonUtilsImpl() in
build_gles2_cmd_buffer.py just iterates over a python dictionary containing the
enums to write them to the file, and when the contents of the dictionary change
the ordering can change as well.

Either way I split this into a separate patch.

https://codereview.chromium.org/689633003/diff/1/gpu/command_buffer/service/g...
File gpu/command_buffer/service/gles2_cmd_decoder.cc (right):

https://codereview.chromium.org/689633003/diff/1/gpu/command_buffer/service/g...
gpu/command_buffer/service/gles2_cmd_decoder.cc:9741: //
TODO(oetuaho@nvidia.com): This is not correct in virtual context mode.
On 2014/10/29 23:35:33, sievers wrote:
> Should we just always say UNKNOWN with virtual contexts since it doesn't
really
> make sense to talk about which context is guilty then?
> 
> You could check
> group()->feature_info()->workarounds().use_virtualized_gl_contexts here.

Yep, that sounds like it would work, probably a better idea than changing
behavior for GetGraphicsResetStatus.

https://codereview.chromium.org/689633003/diff/1/ui/gl/gl_gl_api_implementati...
File ui/gl/gl_gl_api_implementation.cc (right):

https://codereview.chromium.org/689633003/diff/1/ui/gl/gl_gl_api_implementati...
ui/gl/gl_gl_api_implementation.cc:445: #if !defined(NDEBUG)
On 2014/10/29 22:21:21, Ken Russell wrote:
> Please use #if DCHECK_IS_ON instead. Our Release mode bots use
> dcheck_always_on=1.

Got it, will do.

[oetuaho-nv, 2014-10-31 10:22:40]

Review comments addressed, since the changes were relatively trivial I'll
proceed to commit.

[oetuaho-nv, 2014-10-31 10:22:45]

The CQ bit was checked by oetuaho@nvidia.com

[commit-bot: I haz the power, 2014-10-31 10:22:53]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/689633003/20001

[commit-bot: I haz the power, 2014-10-31 11:19:28]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2014-10-31 11:20:33]

Patchset 2 (id:??) landed as
https://crrev.com/37cc50e7e5f15299040d1b535929d0212aa06b9a
Cr-Commit-Position: refs/heads/master@{#302249}