New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 664488 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

GPU disabled in single-process mode on Windows, NVIDIA hardware due to GPU rasterization

Project Member Reported by kkinnu...@nvidia.com, Nov 11 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.87 Safari/537.36

Steps to reproduce the problem:
0. Have a recent NVIDIA card 
1. content_shell --single-process
2. look at the content_shell.log

What is the expected behavior?
Compositing done with GPU

What went wrong?
[22072:16744:1111/142906:1331108406:ERROR:browser_gpu_channel_host_factory.cc(125)] Failed to create channel.

Did this work before? Yes Before https://codereview.chromium.org/2316873002

Chrome version: 54.0.2840.87  Channel: canary
OS Version: 10.0
Flash Version: Shockwave Flash 23.0 r0

I think this is due to "preliminary feature blacklist" vs "feature blacklist" mismatch.

The browser process will use GPUInfo populated with the "device" information to resolve preliminary blacklist to have only 1 entry (vpx).

The GpuChildThread will initialize in-process GPU process. This will re-initialize GPUInfo, but this time only with GL information, not "device" information. 

GpuChildThread will notify back to GpuProcessHost::OnInitialized, with the GPUInfo that does not have device info.

Later on when the GpuProcessHost queries GpuDataManagerImpl::GpuAccessAllowed, the condition fails where the two above mentioned lists differ.

(BTW: there's also re-entrancy problem with GpuDataManagerImpl initialization, where functions like GpuDataManagerImplPrivate::EnableSwiftShaderIfNecessary call GpuDataManagerImpl::GpuAccessAllowed before the members are actually initialized.)
 
Cc: rbasuvula@chromium.org
Labels: TE-NeedsTriageHelp
Components: Internals>GPU
Labels: M-56
Ping, could you assign this to the respective person? I think he'd know how to assess this. jbauman or zmo

Comment 4 by ajuma@chromium.org, Dec 9 2016

Cc: jbau...@chromium.org
Owner: zmo@chromium.org
Status: Assigned (was: Unconfirmed)

Comment 5 by zmo@chromium.org, Dec 10 2016

Status: Started (was: Assigned)
OK, I can take a look at this.

Comment 6 by zmo@chromium.org, Dec 13 2016

OK, it is the accelerated_vpx_decode that is only blacklisted on full GPUInfo, and that blocks the entire GPU process.  Per offline discussion with jbauman, this is indeed (unfortunately) a feature that needs to cause gpu process to be blocked.  Let me dig further to see if we can resolve this some other way.
Based on the initial report, it seems like what's causing the issue is not vpx (which is in the preliminary blacklisted features, so should be fine) but rather some other feature that's blacklisted. I don't know which that would be.
IIRC:
Preliminary blacklist has vpx and gpu rasterization
Full blacklist has vpx

This is due to linked patch, which enables gpu rasterization on specific nv hardware. The hardware exclusion can not work unless one has the full device info.

Comment 9 by zmo@chromium.org, Dec 13 2016

So here is the messy situation:

On launch, preliminary_blacklist contains 0 features, full_info_blacklist contains ACCELERATED_VPX_DECODE, so GPU process is blocked. Somehow there is a GPUInfo update, and preliminary_blacklist contains 1 feature (ACCELERATED_VPX_DECODE), and full_info_blacklist contains 2 features (ACCELERATED_VPX_DECODE, RASTERIZATION), again, GPU process is blocked.

In theory (regular Chrome run), preliminary_blacklist once initialized, it should never be updated.  So the order of steps are really messed when passing in --single-process. It will probably require quite some energy to fix it, and testing it to make sure it won't regress. Since it's not supported code path, I suggest not to spend efforts on it.

To enable you to still have GPU in --single-process mode, now we will just NOT blocking GPU access on --single-process mode. CL will be uploaded soon.
Project Member

Comment 10 by bugdroid1@chromium.org, Dec 14 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/66731ee5c810af897ee9029a2054aca682091d30

commit 66731ee5c810af897ee9029a2054aca682091d30
Author: zmo <zmo@chromium.org>
Date: Wed Dec 14 20:38:29 2016

Don't block GPU process access in single-process mode.

BUG= 664488 
TEST=content_unittests,gpu is enabled in win/NVidia
R=kbr@chromium.org,kkinnunen@nvidia.com

Review-Url: https://codereview.chromium.org/2569413002
Cr-Commit-Position: refs/heads/master@{#438612}

[modify] https://crrev.com/66731ee5c810af897ee9029a2054aca682091d30/content/browser/gpu/gpu_data_manager_impl_private.cc
[modify] https://crrev.com/66731ee5c810af897ee9029a2054aca682091d30/content/browser/gpu/gpu_data_manager_impl_private.h

Comment 11 by zmo@chromium.org, Dec 14 2016

Status: Fixed (was: Started)
This should unblock you from whatever you are doing.
Thanks!

Sign in to add a comment