1818042 - (webgpu-workers) [meta] Re-enable WebGPU in worker threads

Status: NEW

(Core :: Graphics: WebGPU, enhancement, P1)

Description

[Jim Blandy :jimb]

Per spec, WebGPU is available in web workers, both for running compute shaders and for rendering to OffscreenCanvas elements. However, Bug 1808820 disabled WebGPU in workers, because that is not part of our limited goals for our first milestone, Bug 1746245.

Fixing this bug will entail actually fixing the problems described in bug 1808820: we need our WebGPU implementation to correctly handle the parent window being closed, not just be inaccessible due to being in a web worker.

Comment 2

[n3tfr34k]

Still waiting for it. So, thumbs up (+1).

Comment 3

[sk.bizport]

Project that i am working on heavily uses workers and relies on WebGPU compute pipeline. What is the expected timeline for enabling webgpu in worker on linux?

Thx

Comment 4

[Andrew Osmond [:aosmond] (he/him)]

(In reply to sk.bizport from comment #3)

Project that i am working on heavily uses workers and relies on WebGPU compute pipeline. What is the expected timeline for enabling webgpu in worker on linux?

Thx

There should be a new pref dom.webgpu.workers.enabled that you can flip in nightly if you want to test using workers. I don't have a timeline on when it will get enabled by default, but hopefully this unblocks you. If you run into any issues with workers, please file bugs against this metabug! Thanks :)

Comment 6

[Jim Blandy :jimb]

We haven't been treating worker support as a priority, but if it's blocking popular demos, then maybe we need to reconsider that. But I don't think we can realistically expect to put time into this within the next two months.

Comment 7

[Jim Blandy :jimb]

Priority P3, "missing core functionality" seems appropriate for this.

Comment 8

[Jim Blandy :jimb]

:jrmuizel's sense is that worker usage is going to be pretty common for WebGPU content. His feeling is that, while it would be fine to ship to release with WebGPU available only on the main thread, we shouldn't announce WebGPU support until it is available in workers. That seems reasonable to me.

Since we have removed all wgpu interaction from the content process, it seems to me that worker support should be quite straightforward. I would want to audit our canvas interactions, but otherwise our DOM API implementation just doesn't interact with anything but IPDL.

Comment 9

[James Graham [:jgraham]]

Marking as a webcompat bug because we have broken sites that depend on this.

Comment 10

[Erich Gubler [:ErichDonGubler]]

To :jimb's point: we may decide to resolve this early, if the lift is light.

At Jim's request, I ran an experiment to assess what effort we have left for making this work: I triaged WebGPU CTS failures from try:56e8efffb306. For some reason, webworker chunks are being run in tier 2 contexts, despite implementation-status: backlog being set. Mysterious! Otherwise, practically all worker tests I observed were timing out. Not sure what the deal is yet.

Next steps: (1) Determine root cause for worker test timeouts, (2) figure out why WPT tests aren't filtering as we expect.

Comment 11

[Erich Gubler [:ErichDonGubler]]

One site that exercises this as part of introductory material for WebGPU: https://shi-yan.github.io/webgpuunleashed/Control/using_web_workers.html

Comment 12

[Jim Blandy :jimb]

FWIW, we do have mochitests that use WebGPU in workers, like dom/webgpu/mochitest/test_submit_render_empty.worker.js, run from dom/webgpu/mochitest/mochitest.toml, which sets dom.webgpu.workers.enabled=true.

So while this is obviously not adequate coverage, it's at least the case that we can get an adapter and a device, and submit a draw call.

Comment 13

[Nick]

Still broken for known examples, including in Firefox Nightly with all the necessary dom.webgpu.* flags set to true.
https://shi-yan.github.io/webgpuunleashed/code/code.html#3_04_worker
https://webgpu.github.io/webgpu-samples/?sample=worker

...Both links known to work in latest Chrome 129.0.6668.90 and latest Edge Version 129.0.2792.79.

Can we get this fixed, please? It's been open for a couple of years now.

Comment 14

[Erich Gubler [:ErichDonGubler]]

@Nick: This task is a P3, which means it nominally sits at a lower priority than the sizeable lists in P1 and P2 currently listed for the WebGPU team here: https://github.com/orgs/gfx-rs/projects/7/views/5 As a member of that team, my best guess is that it will still take a few months before this functionality is ready.

If you're interested in following along with those pages specifically, then feel free to follow the associated bugs. The page you've linked to in WebGPU Unleashed is being tracked at bug 1911497, which is already linked against this bug. Official WebGPU samples are currently being tracked in bug 1806659, and we're open to more specific tracking issues for pages there, if you want to file one.

Are you a stakeholder in those pages being unblocked? If so, could you comment in those bugs with more information about what you're trying to do or build?

Comment 15

[Nick]

(In reply to Erich Gubler [:ErichDonGubler] from comment #14)

@Nick: This task is a P3, which means it nominally sits at a lower priority than the sizeable lists in P1 and P2 currently listed for the WebGPU team here: https://github.com/orgs/gfx-rs/projects/7/views/5 As a member of that team, my best guess is that it will still take a few months before this functionality is ready.

If you're interested in following along with those pages specifically, then feel free to follow the associated bugs. The page you've linked to in WebGPU Unleashed is being tracked at bug 1911497, which is already linked against this bug. Official WebGPU samples are currently being tracked in bug 1806659, and we're open to more specific tracking issues for pages there, if you want to file one.

Are you a stakeholder in those pages being unblocked? If so, could you comment in those bugs with more information about what you're trying to do or build?

Thanks @Erich for your reply and for linking the relevant issues. I'd be content just to get a notification when this fix / feature is ready, so I'll sub there.

Stakeholder, not sure if you mean that in official MDN sense? -- I'm just trying to build my app to run seamlessly in Chrome, Edge and FF. Main thread is best left free for other tasks than WebGPU calls, but it's not impossible to polyfill this for the time being by shifting other logic out to other web worker threads.

Comment 16

[Erich Gubler [:ErichDonGubler]]

@Nick: If you're writing an app and trying to use WebGPU, then I consider you a stakeholder as an app developer! 🙂 That's very helpful for us; currently, we've been using some pretty abstract criteria for prioritizing tasks on the WebGPU team. We recognize this collectively, and have tried to be sensitive to actual humans having their apps limited by a specific issue. We'd love to know what app you're building, specifically, but if you'd prefer to keep that information, that's understandable.

Let us know if you keep running into pain points with your workaround—if you're hard-blocked on something like this then that's already a bigger deal for us.

Comment 17

[Nick]

@Erich, a warm welcome indeed! Thanks. Perhaps we can be of mutual assistance. I will let you know if it becomes more urgent.

It is a first / third person 3D game with a specialised (non-triangles based) renderer. Without too much detail, there is a good amount of graphics work that happens on 1-2 dedicated (non-main) threads. Currently there is only 1 such thread, but I foresee these 2 for double buffering the preliminary CPU-rendered data so it is always ready in time for the GPU to receive that buffer and work over it, per-pixel, before display. I have no idea yet if each such thread will be able to submit to WebGPU independently or if this could cause synchronisation issues.

This rendering algorithm used on the CPU is not at all well suited to GPU, being highly dependent at each step on prior results. I have tested it on GPU some months ago, and found this to be the case, in line with my expectations.

There will also be a game logic thread and an AI thread. Assume 4, maybe 5 threads in constant use, including the main thread to coordinate whatever else needs to be done -- plus non-blocking DOM / UI stuff work. As you can see, with a fair number of things going on, it would probably be ideal to keep the main thread free and make use of dedicated threads for all non-GPU number crunching.

Comment 18

[Erich Gubler [:ErichDonGubler]]

This is a P1 in our GitHub board now; sync'ing priority! 🎉

Comment 19

[Erich Gubler [:ErichDonGubler]]

Nick, can you confirm that your own app isn't working with web workers? If so, what issues are you running into?

Comment 20

[Erich Gubler [:ErichDonGubler]]

Nick:

I have no idea yet if each such thread will be able to submit to WebGPU independently or if this could cause synchronisation issues.

There shouldn't be any synchronization issues, since WebGPU in Firefox is implemented as messages sent to a single thread.

Comment 21

[Nick]

(In reply to Erich Gubler [:ErichDonGubler] from comment #19)

Nick, can you confirm that your own app isn't working with web workers? If so, what issues are you running into?

Unfortunately I get a silent failure @Erich. The same happens with the existing samples e.g. Worker.

Some other (main thread) samples such as Deferred Rendering are working fine. In my own code, because of this bug, which I found around May this year, I can toggle exactly the same client render code to run on either main thread (where it works fine) or worker thread (where it fails silently, unless I'm missing something in my debugging approach).

What are you seeing? I guess the same? Aside from supplying you my entire game code, what can I do to assist?

Comment 22

[Nick]

...One odd thing I did notice about this is that I have a minimap overlay canvas (regular 2D context) that I render to, sitting over this one that fails to render. What is strange is that I see a lot of flickering of the entities I'm rendering on the minimap, when the worker WebGPU code fails. That is, my game code + requestAnimationFrame continues to run, but it seems to interfere with the overlaid (0 alpha background) overlay canvas -- which IMO should not happen, and ceases to happen the moment I disable the worker/WebGPU first-person view renderer that sits on the canvas beneath.

Comment 23

[Erich Gubler [:ErichDonGubler]]

I suspect that we might be running unto bug 1882960 with the silent failure.