1951219 - [webgpu] Demo at https://jtkyber.github.io/game_engine/ is very slow to interact without using much GPU

Status: NEW

(Core :: Graphics: WebGPU, defect)

Description

[Mayank Bansal]

Go to https://jtkyber.github.io/game_engine/
Let hte game engine load . may take a minute
Once you see the demo on screen, click on the screen
Move by pressing WASD.

AR: Very slow to interact. Chrome is much faster/smoother.
Profile: https://share.firefox.dev/3D1yzTf

There are also some errors:
14:38:33.442 unreachable code after return statement
main.js:736:4
14:38:33.491 injected firefox content.js:239:17
14:38:33.580 Uncaptured WebGPU error: Shader module creation failed: Parsing error
14:38:33.580
Encountered one or more errors while creating shader module "cullingShaderModule"
14:38:33.580
WebGPU compilation info for shader module "cullingShaderModule" (1 error(s), 0 warning(s), 0 info)
14:38:33.580

Shader 'cullingShaderModule' parsing error: invalid switch value
┌─ wgsl:49:26
│
49 │ case 0: {
│ ^ expected unsigned integer
│
= note: suffix the integer with a u: 0u

14:38:46.813 Uncaptured WebGPU error: ShaderModule with 'cullingShaderModule' label is invalid
14:38:50.668 Disabling mouse acceleration is not supported 4 controller.ts:227:25
14:39:15.639 Uncaptured WebGPU error: Not enough memory left.
14:39:15.648 Uncaptured WebGPU error: In a set_bind_group command, caused by: BindGroup with 'Joint Matrices Bind Group' label is invalid
14:39:15.648 Uncaptured WebGPU error: Command encoder is locked by a previously created render/compute pass. Before recording any new commands, the pass must be ended.
14:39:15.648 Uncaptured WebGPU error: Command encoder is invalid
14:39:15.648 Uncaptured WebGPU error: CommandBuffer with '' label is invalid

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Seems like this could be fixed by https://github.com/gfx-rs/wgpu/pull/7250

Comment 2

[Erich Gubler [:ErichDonGubler] (he/him)]

This bug describes two distinct problems:

1. Shader compilation failure due to bug 1829879 which, as Jeff says, is likely wgpu#7250.
2. A potential performance issue that is likely not going to be resolved by (1).

Comment 3

[Andy Leiserson [:aleiserson]]

This is working for me now (Mac M1), and performance seems comparable to Chrome. Mayank, do you still see the performance issue?

Comment 4

[Mayank Bansal]

There is a huge difference between Nightly and Chrome.
Gecko profiler: https://share.firefox.dev/4c8Zc5O
Samply: https://share.firefox.dev/4izwVaN

Comment 5

[Andy Leiserson [:aleiserson]]

The profiles show ~10 second periods spent in dxcompiler.dll, so it seems like there is a Windows-only performance issue here.

Comment 6

[Mayank Bansal]

SAmply profile for Chrome: https://share.firefox.dev/423RfKv
AFAIk, they also use the same DXC compiler as we do.

Comment 7

[Andy Leiserson [:aleiserson]]

AFAIk, they also use the same DXC compiler as we do.

Indeed. I did not mean to suggest that the problem lies with DXC, just that the issue only manifests when using DXC. My guess is that either we are translating WGSL to very inefficient HLSL, or there's something else about how we invoke DXC in this case.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

(In reply to Mayank Bansal from comment #6)

SAmply profile for Chrome: https://share.firefox.dev/423RfKv
AFAIk, they also use the same DXC compiler as we do.

Indeed. Chrome compiles the shaders in 135ms: https://share.firefox.dev/4hQmmiu