Hello! I'm curious if anyone here has a good idea about interleaving works between a compute shader and a fragment shader. Some relevant details: • My app is built with Rust and wgpu, and I'm running on an M1 Macbook Pro. • I have a single encoder with a compute pipeline and a render pipeline. • The compute shader writes to a storage buffer defined like this:

@group(0) @binding(2) var<storage, read_write> output: array<vec4<f32>>;

• The fragment shader reads from the same buffer. Basically, each fragment is just one element of the

vec4<f32>

. The fragment shader is very simple, and doesn't touch anything else in the storage buffer. I've added timestamp queries to the pipeline, and what I'm seeing is this:

Duration #1: 47.800208ms
Duration #2: 47.809876ms
Frame time: 51.2545ms

Duration #1

is computed from the compute shader timestamps (the duration between the beginning and end of the compute pass) and

Duration #2

is the time for the render pass, computed the same way.

Frame time

is measured on the CPU. I expected the duration of the compute shader and fragment shader to add up to the frame time (approximately). But it doesn't and I'm confused about why! Could it be due to interleaving of the compute pass and render pass? If so, I'm curious how the synchronization works. How does the GPU figure out the dependencies between the write (a compute shader invocation) and the reader (fragment shader invocation)? I don't have any explicit synchronization, but I'm also not seeing any tearing or anything that would indicate that there is a data race between the shaders.

those durations are suspiciously close for being times of completely different processes! plus, is it possible that the compute for frame N was run in frame N-1?

I agree. My colleague’s theory was that they are interleaved, and that they are both running at the same time but that they are somehow synchronized by the runtime. I’m skeptical that we’d get that for free.

I also vote “unreliable timestamps”

I did a bit of digging in the Metal docs and they do mention some kind of magic auto-parallelism:

Metal automatically tracks dependencies between the compute and render passes. When the sample sends the command buffer to be executed, Metal detects that the compute pass writes to the output texture and the render pass reads from it, and makes sure the GPU finishes the compute pass before starting the render pass.

https://developer.apple.com/documentation/metal/compute_passes/processing_a_texture_in_a_compute_function

There are pretty good graphics debugging tools in Xcode/Instruments. If you can somehow hook them up to the Metal part of whatever you’re running, they would give you detailed information about what’s running where and when. https://developer.apple.com/documentation/xcode/metal-debugger/

@Sam Gentle That's interesting, thanks! Though I'm still skeptical that it could automatically determine the fine-grained dependencies between individual invocations of the compute/render passes. From the wording it sounds more like it would wait until the compute pass is complete before starting the render pass.