Passes and Synchronization

[Jean-Colas Prunier]

Hi Dawn's team,

I appreciate working with Dawn's API so far. It's super enjoyable (and yes I still consider contributing once I have some other commitments out of the way)).

I have a couple of questions that I will ask in separate threads. This one is about pass synchronization. I am testing rendering several passes that each have their own command buffers. Using the parallelism of the queues, they should be processed in parallel. However, some of these passes are dependent on one another. E.g., I render into textures that are then composed, and then the final composed texture is rendered to the screen, so 3 steps:

- render the textures

- compose the textures in a single one (CopyToTexture)

- render the composed texture to the screen.

So far, I didn't see any out-of-sync issues. Still, I wanted to know if this could be a problem or whether Submit was actually processing potential commands and only returning when they have all been consumed (I understand they should be executed in the order they were inserted but of course, the order in which they finish is not guaranteed to be that order). As I don't see any pipeline barriers, events, and subpass dependencies mechanism, I was wondering what were your recommendations / take on this topic.

Thanks.

[Mark Sibly]

AFAIK (and I may be way off here) there is only one queue per device, and nothing happens until it gets enqueued, so while I guess you could create multiple command buffers in parallel using threading, they are still ultimately added to the device queue one at a time, and the commands they contain will get executed in the order the command buffers were enqueued.

I'd love to have this clarified though...!

[Corentin Wallez]

What Mark wrote is correct. There is an ordered queue-timeline in the WebGPU spec. Queue operations like submit, but also writeBuffer and friends are executed on the GPU in the order in which they are specified. The WebGPU implementation ensures there is enough synchronization to avoid data races. Commands in queue.submit() are executed in order, as well as commands inside them. Places where you can have races are everything inside a single render pass (though the order of blending / depth test is ordered for each pixel) (the only way to see these races is when using a writable storage resource in a fragment shader), and invocations of a dispatchWorkgroups call. Hope this helps!

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/32447e59-98a7-4a8b-81d4-6103167ee1f2n%40googlegroups.com.

[Jean-Colas Prunier]

Yes it helps). Thank you. haven't got to testing writable storage and workgroups yet, but I will get to that at some point. Thanks for the answers.