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

Issue 643362 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug



Sign in to add a comment

enabling webgl2 disables webgl1

Reported by ryan.g...@gmail.com, Sep 1 2016

Issue description

Chrome Version       : 53.0.2785.89 m (64-bit)
URLs (if applicable) : http://webglreport.com/
Other browsers tested: n/a

What steps will reproduce the problem?
(1) verify webgl1 works in chrome (ie. @ http://webglreport.com/ )
(2) restart chrome with '--enable-unsafe-es3-apis' command line flag
(3) attempt to use webgl1 or webgl2, both fail (ie. @ http://webglreport.com/ )

What is the expected result?
webgl1 should continue working even if webgl2 fails.

What happens instead?
Both webgl1 and webgl2 fail.

Please provide any additional information below. Attach a screenshot if
possible.

This behavior has been observed on windows 7 with an Intel HD 4000 graphics chip and windows 7 with an nvidia quadro k4000.  Both run webgl1 without issue.  Both fail to run webgl1 when '--enable-unsafe-es3-apis' is used.
 

Comment 1 by kbr@chromium.org, Sep 1 2016

Cc: -vangelis@chromium.org zmo@chromium.org
Components: -Blink Blink>WebGL
Status: WontFix (was: Unconfirmed)
Please test with Chrome Canary. We don't expect the ES 3.0 / WebGL 2.0 code path to work in Chrome Stable yet.

I see identical behavior in 55.0.2846.0 canary (64-bit)

webgl1 works fine until '--enable-unsafe-es3-apis' is activated.

Comment 3 by kbr@chromium.org, Sep 1 2016

Status: Unconfirmed (was: WontFix)
OK. Please copy/paste the contents of about:gpu from your machine from Canary with --enable-unsafe-es3-apis passed.

Comment 4 by kbr@chromium.org, Sep 1 2016

Components: Internals>GPU>ANGLE Internals>GPU>Internals
Labels: OS-Windows
pdf copies of about:gpu are attached for both machines where I see the issue.  I did both with and without --enable-unsafe-es3-apis.
intel hd 4000 gpu es3 disabled.pdf
113 KB Download
intel hd 4000 gpu es3 enabled.pdf
98.6 KB Download
nvidia quadro k4000 gpu es3 disabled.pdf
113 KB Download
nvidia quadro k4000 gpu es3 enabled.pdf
97.7 KB Download

Comment 6 by zmo@chromium.org, Sep 7 2016

Cc: geoffl...@chromium.org cwallez@chromium.org jmad...@chromium.org
Labels: -Pri-3 Pri-1
Status: Available (was: Unconfirmed)
Intel failure is "No suitable EGL configs found."

NVidia failure is "ANGLE Display::initialize error5: DXGI 1.2 required to present to HWNDs owned by another process."

+ANGLE folks.

Raise to pri-1
Gross.

Not sure about the Intel, but I don't think we'll support WebGL 2 on Intel Windows for a while.

For NVIDIA, our resolution for that error was to ask users to install the platform update for Windows 7, installing DXGI 1.2. Also it won't be present in Windows 8 or 10. I don't think there's a good solution for this presently, if that message is showing up. :(

Comment 8 by zmo@chromium.org, Sep 7 2016

Cc: yang...@intel.com yunchao...@intel.com qiankun....@intel.com
Can we summarize the issues with Windows Intel and let our Intel colleagues know as soon as possible?  Maybe they can do something to help the situation.  Launching WebGL2 without Windows on Intel will be a much less than perfect situation.
Cc: jiajia....@intel.com jiawei.s...@intel.com
sure, we will take a look. 
From what I understand ANGLE is erroring on eglInitialize for D3D11, making no backend type available that supports ES3 and preventing WebGL completely. Shouldn't Chrome be able to fallback to trying ES2 contexts in that case? In gl_surface_egl.cc::ChooseConfig we would try getting a ES3 config, and if none is available, fallback to an ES2 config.

Comment 11 by zmo@chromium.org, Sep 7 2016

Yes, we should implement fallback rather than disable GPU. Then it will just be WebGL2 that's unavailable.
Ah I think I get it. 

My original comment was prompted by this message:

NVidia failure is "ANGLE Display::initialize error5: DXGI 1.2 required to present to HWNDs owned by another process."

In this case D3D11 is unavailable. So maybe what's happening is D3D11 is unavailable and we're not falling back to D3D9/WebGL 1 because of the enable-unsafe-es3-apis flag.
Owner: geoffl...@chromium.org
Status: Started (was: Available)
I can handle the fallback to ES2.
Mo and Intel folks, I will follow-up via email about the WebGL 2 on Intel situation.
Project Member

Comment 15 by bugdroid1@chromium.org, Sep 8 2016

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

commit d5d623aed82374fffde513ed8de88346a14aea42
Author: geofflang <geofflang@chromium.org>
Date: Thu Sep 08 13:09:33 2016

If ES3 EGL config selection fails, fall back to ES2.

BUG= 643362 

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

[modify] https://crrev.com/d5d623aed82374fffde513ed8de88346a14aea42/ui/gl/gl_context_egl.cc
[modify] https://crrev.com/d5d623aed82374fffde513ed8de88346a14aea42/ui/gl/gl_surface_egl.cc

Project Member

Comment 16 by bugdroid1@chromium.org, Sep 8 2016

Labels: merge-merged-2854
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d5d623aed82374fffde513ed8de88346a14aea42

commit d5d623aed82374fffde513ed8de88346a14aea42
Author: geofflang <geofflang@chromium.org>
Date: Thu Sep 08 13:09:33 2016

If ES3 EGL config selection fails, fall back to ES2.

BUG= 643362 

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

[modify] https://crrev.com/d5d623aed82374fffde513ed8de88346a14aea42/ui/gl/gl_context_egl.cc
[modify] https://crrev.com/d5d623aed82374fffde513ed8de88346a14aea42/ui/gl/gl_surface_egl.cc

Status: Fixed (was: Started)

Sign in to add a comment