WebGPU: ServiceWorker and SharedWorker support

[beaufortfrancois]

Request for Mozilla Position on an Emerging Web Specification

• Specification title: WebGPU: ServiceWorker and SharedWorker support
• Specification or proposal URL (if available): https://gpuweb.github.io/gpuweb/#navigator-gpu
• Explainer URL (if available): API should be exposed to ServiceWorker gpuweb/gpuweb#4197
• Proposal author(s) (@-mention GitHub accounts): @beaufortfrancois
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional): @jimblandy @kdashg

Other information

ServiceWorker and SharedWorker support have not yet been implemented in any browser, but have been approved by the GPU for the Web Community Group, with representatives from Chrome, Firefox, and Safari. See minutes.

[asutherland]

This should definitely be fine on SharedWorker.

For ServiceWorkers we've tried to avoid exposing blocking / synchronous APIs because they defeat the point of a ServiceWorker being able to process events in a timely fashion. (And even though WebExtensions MV3 has blurred the meaning of ServiceWorkers, they have still been repurposed to respond to events in a timely fashion, so the original rationale holds up.) In those cases of blocking APIs, enabling nested workers in ServiceWorkers has been proposed at w3c/ServiceWorker#1529 in the SW WG and whatwg/html#8362 in HTML.

Since it seems like the API is explicitly async, I think the question then becomes one of whether data (de)serialization needs to happen on the API thread, and if so if general idioms would take appreciable time. (For example, a common problem for people trying to throw workers at things is just the immense overhead of structured serialization of a complex object graph which inherently needs to happen synchronously with respect to the global.) My presumption would be WebGPU can be implemented in such a way that (de)serialization is not as much of a concern and that the API calls might have a similar level of expense as structured serialization, but that's an argument for just letting the API calls happen in the SW rather than adding the overhead to postMessage to a nested dedicated worker (which we don't yet have).

That said, it would definitely be good to get a Gecko WebGPU domain expert to confirm that we don't expect general usage to interfere with a ServiceWorker's responsiveness.

[jimblandy]

WebGPU doesn't have any expensive synchronous operations in the JS process. Everything is designed to be streamed to the GPU process. There is no synchronous readback in WebGPU, like WebGL's readPixels: WebGPU's analogous mapAsync returns a promise that is resolved when the requested data is available in the caller's process.

Firefox's WebGPU implementation uses IPDL shared memory to transfer large data (GPUBuffer contents) to the GPU process. WebGPU Shading Language (WGSL) programs - source code for programs to be run on the GPU - are transferred to the GPU process as IPDL nsCString values. Generally, the structures being transferred over IPDL like GPUBindGroupDescriptor are not especially large.

@asutherland Does that answer your questions?

[asutherland]

Yeah, sounds fine then. Thanks for the expert context!