Check for a restarted GPU process in OnCreateViewCommandBuffer.

Check for a restarted GPU process in OnCreateViewCommandBuffer.

Both OnEstablishGpuChannel and OnCreateViewCommandBuffer must handle
the case where the GPU process was lost and restarted for correctness.

This doesn't fix all of the flakiness of the context_lost stress test
on the Mac Debug GPU bots, but is a necessary first step.

BUG=365904
TEST=src/content/test/gpu/run_gpu_test.py context_lost --browser=debug --show-stdout -v --page-filter=WebGLContextLostFromGPUProcessExit --page-repeat=30 --extra-browser=args="--enable-logging --vmodule=*content/browser/gpu*=2,*content/common/gpu/client*=2"

[Ken Russell (switch to Gerrit), 2014-05-08 02:57:33]

Please review. Thanks.

[piman, 2014-05-08 03:29:21]

https://codereview.chromium.org/270633008/diff/1/content/browser/renderer_hos...
File content/browser/renderer_host/gpu_message_filter.cc (right):

https://codereview.chromium.org/270633008/diff/1/content/browser/renderer_hos...
content/browser/renderer_host/gpu_message_filter.cc:184:
CAUSE_FOR_GPU_LAUNCH_WEBGRAPHICSCONTEXT3DCOMMANDBUFFERIMPL_INITIALIZE);
So, relaunching the GPU process is not actually good, because while it will give
you a context, it will be on a different channel than the GpuChannelHost you
asked it from.
So on the renderer side, you will have a discrepancy, and trying to send
messages to this command buffer will go on the wrong/old channel and fail.

I think we had a discussion about this with Dana, and the conclusion was IIRC
that we should handle this on the renderer side, if the CreateViewCommandBuffer
fails, that should trigger failure of the GpuChannelHost.

I think that's https://code.google.com/p/chromium/issues/detail?id=356876

[Ken Russell (switch to Gerrit), 2014-05-09 01:36:13]

+danakj

https://codereview.chromium.org/270633008/diff/1/content/browser/renderer_hos...
File content/browser/renderer_host/gpu_message_filter.cc (right):

https://codereview.chromium.org/270633008/diff/1/content/browser/renderer_hos...
content/browser/renderer_host/gpu_message_filter.cc:184:
CAUSE_FOR_GPU_LAUNCH_WEBGRAPHICSCONTEXT3DCOMMANDBUFFERIMPL_INITIALIZE);
On 2014/05/08 03:29:21, piman wrote:
> So, relaunching the GPU process is not actually good, because while it will
give
> you a context, it will be on a different channel than the GpuChannelHost you
> asked it from.
> So on the renderer side, you will have a discrepancy, and trying to send
> messages to this command buffer will go on the wrong/old channel and fail.
> 
> I think we had a discussion about this with Dana, and the conclusion was IIRC
> that we should handle this on the renderer side, if the
CreateViewCommandBuffer
> fails, that should trigger failure of the GpuChannelHost.
> 
> I think that's https://code.google.com/p/chromium/issues/detail?id=356876

Thanks for the feedback. I'll redo this as a check in the renderer process and
lose the GpuChannelHost from the RenderThreadImpl if this happens.

Currently tracking down remaining race conditions even if this bug were fixed.
Will post either an updated CL or a new one once everything is working reliably.

[danakj, 2014-05-09 17:15:35]

On 2014/05/09 01:36:13, Ken Russell wrote:
> +danakj
> 
>
https://codereview.chromium.org/270633008/diff/1/content/browser/renderer_hos...
> File content/browser/renderer_host/gpu_message_filter.cc (right):
> 
>
https://codereview.chromium.org/270633008/diff/1/content/browser/renderer_hos...
> content/browser/renderer_host/gpu_message_filter.cc:184:
> CAUSE_FOR_GPU_LAUNCH_WEBGRAPHICSCONTEXT3DCOMMANDBUFFERIMPL_INITIALIZE);
> On 2014/05/08 03:29:21, piman wrote:
> > So, relaunching the GPU process is not actually good, because while it will
> give
> > you a context, it will be on a different channel than the GpuChannelHost you
> > asked it from.
> > So on the renderer side, you will have a discrepancy, and trying to send
> > messages to this command buffer will go on the wrong/old channel and fail.
> > 
> > I think we had a discussion about this with Dana, and the conclusion was
IIRC
> > that we should handle this on the renderer side, if the
> CreateViewCommandBuffer
> > fails, that should trigger failure of the GpuChannelHost.
> > 
> > I think that's https://code.google.com/p/chromium/issues/detail?id=356876
> 
> Thanks for the feedback. I'll redo this as a check in the renderer process and
> lose the GpuChannelHost from the RenderThreadImpl if this happens.
> 
> Currently tracking down remaining race conditions even if this bug were fixed.
> Will post either an updated CL or a new one once everything is working
reliably.

Cool, I'm not currently writing anything for
https://code.google.com/p/chromium/issues/detail?id=356876. Looking forward to
seeing your future work here.

[Ken Russell (switch to Gerrit), 2014-05-09 22:52:59]

On 2014/05/09 17:15:35, danakj wrote:
> On 2014/05/09 01:36:13, Ken Russell wrote:
> > +danakj
> > 
> >
>
https://codereview.chromium.org/270633008/diff/1/content/browser/renderer_hos...
> > File content/browser/renderer_host/gpu_message_filter.cc (right):
> > 
> >
>
https://codereview.chromium.org/270633008/diff/1/content/browser/renderer_hos...
> > content/browser/renderer_host/gpu_message_filter.cc:184:
> > CAUSE_FOR_GPU_LAUNCH_WEBGRAPHICSCONTEXT3DCOMMANDBUFFERIMPL_INITIALIZE);
> > On 2014/05/08 03:29:21, piman wrote:
> > > So, relaunching the GPU process is not actually good, because while it
will
> > give
> > > you a context, it will be on a different channel than the GpuChannelHost
you
> > > asked it from.
> > > So on the renderer side, you will have a discrepancy, and trying to send
> > > messages to this command buffer will go on the wrong/old channel and fail.
> > > 
> > > I think we had a discussion about this with Dana, and the conclusion was
> IIRC
> > > that we should handle this on the renderer side, if the
> > CreateViewCommandBuffer
> > > fails, that should trigger failure of the GpuChannelHost.
> > > 
> > > I think that's https://code.google.com/p/chromium/issues/detail?id=356876
> > 
> > Thanks for the feedback. I'll redo this as a check in the renderer process
and
> > lose the GpuChannelHost from the RenderThreadImpl if this happens.
> > 
> > Currently tracking down remaining race conditions even if this bug were
fixed.
> > Will post either an updated CL or a new one once everything is working
> reliably.
> 
> Cool, I'm not currently writing anything for
> https://code.google.com/p/chromium/issues/detail?id=356876. Looking forward to
> seeing your future work here.

Closing this CL in favor of https://codereview.chromium.org/277113002 , which
uses piman's suggestion and fixes all the flakiness of this test I can reproduce
locally on Mac OS.