bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Shader compilation in a WebGL 2 demo takes ~3x time when ANGLE is enabled.




Canvas: WebGL
2 years ago
8 months ago


(Reporter: anthony, Unassigned)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [gfx-noted])


(3 attachments)

Comment hidden (empty)
Blocks: 1247130
No longer depends on: 1247130
Component: General → Canvas: WebGL
Product: Firefox → Core
Whiteboard: [gfx-noted]
Let's add the details here.  What version, how are we enabling/disabling ANGLE, a page as an example.
It looks like this is due to D3D shader compilation being expensive. How many shaders are being compiled?
Flags: needinfo?(robert.goulet)
Perhaps only the first part is D3D shader compilation. It would be good if you could log the time for the shader compilation step to see how much of the 3x start up regression is happening there.
Hi, Robert. Can you shed light on Jeff's question or point us to someone who might be familiar with it? Thanks.

Comment 5

2 years ago
I will provide profiling results after GDC if that's ok? But I agree with Jeff that this is most likely shader compilation.
Sounds great. Thanks again, Robert!
Flags: needinfo?(robert.goulet)

Comment 7

a year ago
Benchmarking a WebGL 2 demo that exhibits this, running the page three times on Windows 10 PC with GTX 980 Ti and i7-5960X.

With webgl.disable-angle=false (default):


avg. of ~44 seconds or so.

With webgl.disable-angle=true:


so with ANGLE, page load times end up being ~3x slower.


a year ago
Summary: Autodesk - When Angle is enabled, loading the page takes a lot more time, ~3x slower → Shader compilation in a WebGL 2 demo takes ~3x time when ANGLE is enabled.

Comment 8

a year ago
Created attachment 8832248 [details]

A benchmark with ANGLE enabled, total loading time is 67 seconds, of which D3D compiler portion is 33 seconds.

Comment 9

a year ago
Created attachment 8832250 [details]

With ANGLE disabled, the total loading time is 34 seconds, more in JS register allocation and so on.
To be clear, the ANGLE contributes indirectly because all the shaders are HLSL and we use the D3D compiler, right?

Comment 11

a year ago
Yeah, that's correct. I don't see the ANGLE codebase itself generating much slowdown here, but it is D3DCompiler.dll that dominates here.


a year ago
Blocks: 1207170
Created attachment 8843203 [details]

I made a simple test using the ghost town demo to compare the shader performance between ANGLE and native OpenGL.

You can see that glLinkProgram is the most prominent factor for the loading time difference. (28.638sec vs 4.159sec) 

It is because in ANGLE's design, they "compile" the shader from GLSL/ESSL to HLSL in glCompileShader, and do actual D3D compilation in glLinkProgram which is the most time-consuming part.

Besides, it is interesting that the most time-consuming D3D compilation is formed by lots of "mini compilation" by an average of 0.087 sec for 327 times.

Maybe we can do the compilation in parallel or async?


a year ago
Duplicate of this bug: 1347135

Comment 14

a year ago
A second test case that shows similar effects, one that is not the same engine which was reported originally, but is at least public so easier to share, is the UE4 Zen Garden demo:


where running Firefox Nightly 55.0a1 (2017-03-21) (64-bit) on desktop PC HASWELL, which is

Windows 10 Home 64-bit
3.0 GHz Intel 8-Core i7-5960X
32GB of RAM


ANGLE disabled (webgl.disable-angle;true):

> "totalRenderTime": 18871.894999999997,
> "shaderCompilation": 3140.0150000000012,

and ANGLE enabled (webgl.disable-angle;false):

> "totalRenderTime": 31248.83, (+65.59%)
> "shaderCompilation": 8476.345, (+169.95%)
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.