Open Bug 1247135 Opened 8 years ago Updated 1 year ago

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

Categories

(Core :: Graphics: CanvasWebGL, defect, P3)

defect

Tracking

()

People

(Reporter: avaughn, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [gfx-noted])

Attachments

(3 files)

      No description provided.
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.
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)
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):

45543.515ms
44224.875ms
43752.875ms

avg. of ~44 seconds or so.

With webgl.disable-angle=true:

16911.91ms
17119.3ms
18685.315ms

so with ANGLE, page load times end up being ~3x slower.
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.
A benchmark with ANGLE enabled, total loading time is 67 seconds, of which D3D compiler portion is 33 seconds.
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?
Yeah, that's correct. I don't see the ANGLE codebase itself generating much slowdown here, but it is D3DCompiler.dll that dominates here.
Attached image compare_angle.png
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 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:

https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html?playback&novsync&cpuprofiler

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
ASUS NVIDIA GeForce GTX 980 Ti

gives:

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%)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: