content: Fix lost context handling when using native GpuMemoryBuffers.

content: Fix lost context handling when using native GpuMemoryBuffers.

This is a redesign of browser side management of GpuMemoryBuffers
to be able to handle GPU process crashes correctly. The following
changes have been made to handle these situations correctly.

1. The BrowserGpuMemoryBufferManager class talks to GpuProcessHost
instances directly and will launch a new GPU process if needed. This
is needed to keep track of what GPU host each buffer belongs to.
Buffers can only be destroyed by the same host that created them and
this change prevents us from making attempts to destroy a buffer
using a different GPU host then it was created by.

2. Improved code reuse between in-process buffers and buffers
allocated for child processes. The result is that we track the
memory usage of not just child process buffers but all buffers
allocated by the manager.

3. Shared memory backed buffers can be used to test GPU process
side allocation of buffers and lost context handling on all
platforms.

BUG=486922
TEST=content_browsertests --gtest_also_run_disabled_tests --gtest_filter=ChildThreadImplGpuMemoryBufferBrowserTests/ChildThreadImplGpuMemoryBufferBrowserTest.*, content/test/gpu/run_gpu_test.py context_lost --extra-browser-args=--enable-native-gpu-memory-buffers --story-filter=GpuCrash.GPUProcessCrashesExactlyOnce

Committed: https://crrev.com/42574bd38067c90223cc496f7aad80ebaf454d13
Cr-Commit-Position: refs/heads/master@{#335540}

[reveman, 2015-06-17 14:16:36]

reveman@chromium.org changed reviewers:
+ dcastagna@chromium.org

[reveman, 2015-06-17 18:28:01]

+mcasas FYI, I have to disable some VideoCaptureBufferPoolTest tests as they are
using BrowserGpuMemoryBufferManager inappropriately.

https://codereview.chromium.org/1189943002/diff/20001/content/browser/rendere...
File content/browser/renderer_host/media/video_capture_buffer_pool_unittest.cc
(right):

https://codereview.chromium.org/1189943002/diff/20001/content/browser/rendere...
content/browser/renderer_host/media/video_capture_buffer_pool_unittest.cc:31: //
media::PIXEL_FORMAT_GPUMEMORYBUFFER
I had to disable this as BrowserGpuMemoryBufferManager::current() is used in
these unit tests. BrowserGpuMemoryBufferManager::current() should not be used
unless we're in mode where we can start a GPU service.

[reveman, 2015-06-17 22:17:52]

reveman@chromium.org changed reviewers:
+ piman@chromium.org

[piman, 2015-06-19 19:29:48]

I have 2 main concerns.

https://codereview.chromium.org/1189943002/diff/20001/content/browser/gpu/bro...
File content/browser/gpu/browser_gpu_memory_buffer_manager.cc (right):

https://codereview.chromium.org/1189943002/diff/20001/content/browser/gpu/bro...
content/browser/gpu/browser_gpu_memory_buffer_manager.cc:86:
base::LazyInstance<BrowserGpuMemoryBufferManager>::Leaky
I'm not crazy about leaving this Leaky, because it stops working after we stop
the IO thread, so we have a clear place to release it.

https://codereview.chromium.org/1189943002/diff/20001/content/browser/gpu/bro...
content/browser/gpu/browser_gpu_memory_buffer_manager.cc:481: if (!valid_handle)
{
Do you need retry logic, like we do for the channel in
BrowserGpuChannelHostFactory?
The problem is that when you get a host in GpuProcessHost::FromID, you don't
know if it's dead or not (because it's fundamentally racy, it could die between
when you got the GpuProcessHost* and when you send the message). So if the GPU
process was previously dead, you will fail to create a GMB, instead of creating
a new GPU process.

[reveman, 2015-06-22 17:09:12]

ptal

https://codereview.chromium.org/1189943002/diff/20001/content/browser/gpu/bro...
File content/browser/gpu/browser_gpu_memory_buffer_manager.cc (right):

https://codereview.chromium.org/1189943002/diff/20001/content/browser/gpu/bro...
content/browser/gpu/browser_gpu_memory_buffer_manager.cc:86:
base::LazyInstance<BrowserGpuMemoryBufferManager>::Leaky
On 2015/06/19 at 19:29:48, piman (Very slow to review) wrote:
> I'm not crazy about leaving this Leaky, because it stops working after we stop
the IO thread, so we have a clear place to release it.

Makes sense. Done.

https://codereview.chromium.org/1189943002/diff/20001/content/browser/gpu/bro...
content/browser/gpu/browser_gpu_memory_buffer_manager.cc:481: if (!valid_handle)
{
On 2015/06/19 at 19:29:48, piman (Very slow to review) wrote:
> Do you need retry logic, like we do for the channel in
BrowserGpuChannelHostFactory?
> The problem is that when you get a host in GpuProcessHost::FromID, you don't
know if it's dead or not (because it's fundamentally racy, it could die between
when you got the GpuProcessHost* and when you send the message). So if the GPU
process was previously dead, you will fail to create a GMB, instead of creating
a new GPU process.

Good point. Added retry logic to latest patch.

Note that there's still a problem with clients not being able to tell if a
buffer was lost. It happens to work right now as clients tend to check for
contexts being lost and re-allocate all buffers in that case. I think ideally
we'd have a different mechanism to tell if a buffer is lost. My current plan for
this is to implement it as part of adding support for discardable gpu memory
buffers.

[piman, 2015-06-22 17:58:01]

lgtm

[reveman, 2015-06-22 18:07:11]

The CQ bit was checked by reveman@chromium.org

[commit-bot: I haz the power, 2015-06-22 18:08:47]

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

[commit-bot: I haz the power, 2015-06-22 18:28:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-22 18:28:04]

Try jobs failed on following builders:
  cast_shell_android on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_andr...)

[reveman, 2015-06-22 18:55:30]

The CQ bit was checked by reveman@chromium.org

[commit-bot: I haz the power, 2015-06-22 18:56:48]

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

[commit-bot: I haz the power, 2015-06-22 19:19:01]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-06-22 19:20:06]

Patchset 3 (id:??) landed as
https://crrev.com/42574bd38067c90223cc496f7aad80ebaf454d13
Cr-Commit-Position: refs/heads/master@{#335540}