1962886 - Testcase generating-and-compiling N shaders blocks the content-process. (N=50000)

Status: RESOLVED WONTFIX

(Core :: Graphics: WebGPU, defect)

Description

[Mayank Bansal]

Attachment: webgpu shaders in loop.HTML

Open testcase
Enter 50000
Click on submit button

Firefox: https://share.firefox.dev/4jWBdcJ

Testcase generated by chatgpt based on my prompts. Artificial but maybe it highlights some hotspots?

Comment 1

[Erich Gubler [:ErichDonGubler]]

uh

This is expected behavior, and a classical problem in rendering on native workloads, too. 🙂 When WebGPU users have large wall times in the construction and/or usage of their GPU pipelines, we encourage them to offload to another thread in a worker context, and make their GPU work asynchronous!

Otherwise, you've essentially created a synthetic benchmark for shader transpilation via Naga (N.B., not full shader compilation in a graphics driver; this doesn't happen until a WebGPU pipeline is created). There are two potential points of value I see in this:

1. Finding pathological behavior in that might reasonably affect our users, or is not terribly difficult to fix.
2. Stress testing for resource accumulation, which happens abundantly in the Web's GC contexts (i.e., memory usage in JavaScript programming).

RE: (1): Unfortunately, transpiling 50k "show me a triangle shader with a different color" shaders isn't a realistic use case. It's abstractly interesting, but there isn't a concrete expectation being broken with taking ~8 seconds to transpile them.

RE: (2): We might use a benchmark like this as a baseline for the Naga shader compiler that we don't want to drift too far away from. I'll bring it up with the team in today's team sync.

In any case, this report, as stated, is not something we plan on changing.

Comment 2

[Jim Blandy :jimb]

Since the Naga front end runs in the GPU process, moving the content JS activity to a worker thread won't make any difference: all content, whether in a worker or on the main thread, is talking to the same renderer thread in the GPU process.

For pipeline creation, WebGPU does offer createRenderPipelineAsync and createComputePipelineAsync, which are supposed to offload the backend work to a worker pool. But there is no analogous createShaderModuleAsync.

With that said, though, I don't think this is something we are going to consider a bug. We'll improve Naga's performance when that becomes something that users indicate to us is a problem for them.