@Kangz suggested that I write an issue here:

I haven't thought this through completely, so please excuse any unfocused ramblings :)

TL;DR: I think WebGPU implementations should guarantee a fixed frame latency (so it doesn't change frame latency once an application is running), specify a 'worst case latency' in the spec which implementations must adhere too, and (maybe) provide a way to query the frame latency of a given implementation at startup.

Plus (of course), implementations should strive to keep the frame latency as low as possible.

Why:

Apart from obvious user-experience aspects (low latency == better), e.g. button-to-screen, or head-movement in AR/VR, frame latency also affects the coding side now because WebGPU offers more explicit resource management than WebGL.

Consider dynamic resource updates via async-mapped buffers allocated on demand:

• at the start of a frame, if no mapped buffer is available, a new buffer is created as mapped, otherwise an existing mapped buffer is reused.
• ...during the frame, the buffer is filled with new data
• before queue-submit, the buffer is unmapped, and optionally a copy/blit-operation is recorded in the command encoder
• after queue-submit, a new async-mapping is requested immediately

With a fixed frame-latency, this creates a new buffer each frame at the start of the application until the first async-map request has resolved, and from there on, existing buffers will be reused.

If the frame-latency stays fixed during the entire lifetime of the application, no buffers will be created except during the first N frames.

Now to the problems if the frame latencies varies between WebGPU implementations or even during the lifetime of an application:

• Memory usage basically becomes unpredictable, the total size of staging buffers can be quite big, and each additional frame of latency adds a non-trivial amount of memory usage (not in the WASM heap, but still...), and most of this memory just sits around waiting in the frame pipeline until it's their turn... the longer the 'frame pipeline' the worse.
• If the frame-latency would be completely unpredictable, internal data structures in the app code must be dynamically sized (e.g. queues or ring buffers holding references to the staging buffers).

So ideally we'd have:

• a worst-case frame latency in the spec, so that applications can estimate memory usage and use this for compile-time size of data structures
• a runtime-frame-latency by a given implementation in a given environment (which would be <= the worst-case latency in the spec) that can be queried at startup and doesn't change (which applications can use to tweak their behaviour)
• a guarantee that frame latency is either fixed throughout the application lifetime, or at least doesn't get bigger than the 'worst case latency' across all the implementations and the runtime-latency of a given implementation...

As I said above, there may be other implications/advantages/disadvantages around frame latency that I haven't thought of, but I think it's at least important to raise the issue so it can be discussed :)