Don't create child window for WGL.

Don't create child window for WGL.

This causes a deadlock, so it's not usable. Getting rid of the window at least allows --in-process-gpu to work.

BUG=273220
Committed: https://crrev.com/d62145de7e70360d857c4514a6892cb7f6639315
Cr-Commit-Position: refs/heads/master@{#299388}

[jbauman, 2014-10-11 02:19:33]

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

[Ken Russell (switch to Gerrit), 2014-10-11 03:01:17]

I don't think this solution works in the long term. A plan has been to use ANGLE
on top of OpenGL on Windows where the drivers are robust enough. We still need
to admit GPU process crashes and restarts in our current architecture, and using
--in-process-gpu defeats that ability.

Is there no other feasible way to solve this problem? --use-gl=desktop used to
work even in Chrome's current architecture of separate browser, renderer, and
gpu processes. The break occurred during the switch to Aura. I believe there
must be some workable fix involving teasing apart either the compositor's or
command buffer's initialization.

[jbauman, 2014-10-11 03:36:10]

On 2014/10/11 03:01:17, Ken Russell wrote:
> I don't think this solution works in the long term. A plan has been to use
ANGLE
> on top of OpenGL on Windows where the drivers are robust enough. We still need
> to admit GPU process crashes and restarts in our current architecture, and
using
> --in-process-gpu defeats that ability.
> 
I'll need this anyway if I want to create the child window on a different thread
in the GPU process, so I figured it would make sense to at least check this in
and allow people to test with --in-process-gpu for now.

> Is there no other feasible way to solve this problem? --use-gl=desktop used to
> work even in Chrome's current architecture of separate browser, renderer, and
> gpu processes. The break occurred during the switch to Aura. I believe there
> must be some workable fix involving teasing apart either the compositor's or
> command buffer's initialization.

The only way to do that is to make the command buffer literally never block on
the GPU process, which seems infeasible given its design.

For example, if one compositor creates a gpu context asynchronously, another
compositor could still come along right afterwards and block on the gpu process
for some reason, and there'd still be a deadlock.

So moving the initialization of the child window to somewhere else in the gpu
process seems like the only solution.

[Ken Russell (switch to Gerrit), 2014-10-12 23:11:11]

On 2014/10/11 03:36:10, jbauman wrote:
> On 2014/10/11 03:01:17, Ken Russell wrote:
> > I don't think this solution works in the long term. A plan has been to use
> ANGLE
> > on top of OpenGL on Windows where the drivers are robust enough. We still
need
> > to admit GPU process crashes and restarts in our current architecture, and
> using
> > --in-process-gpu defeats that ability.
> > 
> I'll need this anyway if I want to create the child window on a different
thread
> in the GPU process, so I figured it would make sense to at least check this in
> and allow people to test with --in-process-gpu for now.

OK. This sounds fine as a temporary step toward a complete solution. Please see
below.

> > Is there no other feasible way to solve this problem? --use-gl=desktop used
to
> > work even in Chrome's current architecture of separate browser, renderer,
and
> > gpu processes. The break occurred during the switch to Aura. I believe there
> > must be some workable fix involving teasing apart either the compositor's or
> > command buffer's initialization.
> 
> The only way to do that is to make the command buffer literally never block on
> the GPU process, which seems infeasible given its design.
> 
> For example, if one compositor creates a gpu context asynchronously, another
> compositor could still come along right afterwards and block on the gpu
process
> for some reason, and there'd still be a deadlock.

Could you please provide some more detail on http://crbug.com/273220 about
exactly what the deadlock is? Is the browser's UI thread actually blocked
waiting for the GPU process, or is it blocked for some more indirect reason? The
GpuMsg_ IPCs in src/content/common/gpu/gpu_messages.h are all asynchronous. Does
the browser's UI thread run the browser compositor and issue the GL calls via
the command buffer, or is that work done on another thread in the browser? If
it's done on the UI thread, that seems like it could cause problems on all
platforms. The browser's sub-processes are allowed to block on the browser
process, but the browser's always supposed to be ready to service incoming
requests from renderers and the GPU process -- meaning, in my mind, that its UI
and IO threads are never supposed to block. As you point out, the command buffer
client can always stall waiting for the GPU process to consume commands.

> So moving the initialization of the child window to somewhere else in the gpu
> process seems like the only solution.

As long as this CL is just a step toward a more full solution, LGTM.

[jbauman, 2014-10-13 23:17:45]

The CQ bit was checked by jbauman@chromium.org

[commit-bot: I haz the power, 2014-10-13 23:19:03]

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

[commit-bot: I haz the power, 2014-10-13 23:23:07]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2014-10-13 23:23:58]

Patchset 1 (id:??) landed as
https://crrev.com/d62145de7e70360d857c4514a6892cb7f6639315
Cr-Commit-Position: refs/heads/master@{#299388}