Showing results for 
Search instead for 
Did you mean: 

WebGL issue with HD 5000

We are developing a Qt application with QtWebEngine (which uses Chromium under the hood). When we view certain WebGL content in this application on a specific computer, rendering is often incorrect - objects appear black or near-black, as though lighting and/or texturing is not working properly. And without certain features disabled, WebGL content does not work at all. The same content and app work fine on other hardware; this seems to be specific to the Intel driver and/or GPU hardware that we're using. Details below.

System Setup Information:

System Used: Microsoft Surface Pro 3
CPU SKU: i7-4650U
Processor Line: U series
System BIOS Version: America Megatrends 3.11.2150, 4/26/2017
CMOS settings:
Graphics Driver Version:,
GOP/VBIOS Version:
Operating System: Windows 10 Pro
OS Version:
Occurs on non-Intel GPUs?: No

Steps to Reproduce:
0. Close all open instances of google chrome browser.
1. Launch any recent version of google chrome browser with --use-gl=desktop and --ignore-gpu-blacklist flags.
2. Navigate to a webgl test page such as
*3. The page reports that webgl is disabled even though the hardware supports it (see also chrome://gpu).
4. Once again close all open instances of the browser.
5. Launch the browser again with the above flags, and the additional --disable-es3-gl-context flag.
6. Navigate to
*7. Many examples work fine, but many render objects as black, such as

Expected Results:
At step 3, we expect the spinning cube and a message saying opengl is working.

At step 7, we expect that object surfaces are properly lit and colored.

Actual Results:
As noted, we observe that at step 3, webgl is disabled. And at step 7, we see surfaces as black / unlit.

Additional Information:
If we omit the flags, then Chrome browser uses ANGLE to render WebGL content rather than the system-installed opengl32.dll, and that works fine. Also, if we use a software-only opengl implementation rather than the system-installed one, the content also works fine. So we suspect a fault in the Intel driver and/or the opengl implementation that ships with it.


0 Kudos
0 Replies