The particle example currently submits the compute on the async queue correctly and then render on the main queue as well, but due to the data dependency on particle_buf between the compute and render, they are still executed sequentially

So as an exercise, I will try to rewrite the particle example to have two separate buffers of particle data, one being worked on by the compute task and one being sampled from and rendered just to see if I can get the kind of parallelism I want to see.

Got double buffering working, but maybe I am naive in thinking this should be able to be better?

Do you think that the barrier at the end of the compute task might be preventing something? (it shouldn't? should be intra-queue only?) Or is this just the reality of the hardware?

Been working on the particle example with double buffering the particles.

Hmm, no matter what I do it seems to take roughly the same time in the end. The one outlier I got was one where the driver suddenly decided to schedule the async compute task at the very end of the vertex shader in the particle example, overlapping both vertex and fragmetn work.

I split up the compute workload into chunks and submitted it after the main submission and suddenly this happened and was much faster:

Other than that one exception, I get roughly the same perf from async compute as I get from removing some of the barriers internally between passes on a single queue. I did an unsafe experiment just to see and removed most of the barriers inside blade and submitted everyhitng on the main queue, and got this:

Also tried various permutations of splitting the render task into multiple draws of chunks of particles and splitting the compute into various chunks of compute work, but nothing seems to move the needle greatly

So it is a bit unclear from my experiments here how to get the async compute work to land in an optimal location..

madness

I just wanted to demonstrate in one of the examples how to specify dependencies. But you are totally right to expect the actual parallelism in the particle example. I'll look into it more.

@EriKWDev please take another look.
I've extended the particle example with an option to toggle parallel execution on/off.

When cranking up the spawn rate, I see a strong difference between parallel ON (about 4.8ms) and OFF (about 5.7ms) on my AMD Framework 13. Radeon GPU profiler should agree with that.

Nice with getting access to what queues are available!

I'm afraid we did the same thing with the example xD But nice, now the example contains the parallelism.

The problem I tried to point out with the measurements was that my gains were very inconsistent frame to frame, and the best performance I got when the compute task overlapped with the vertex shading in this particle example.

But with this API I don't have the granularity to specify that it specifically run with the vertex and not the fragment.

In the game however, multiple encoders should be enough. We probably want the raytracing compute to always overlap with the shadowmap generation and reflection pass, and I think I can achieve it with multiple encoders and correct after: &[] syncpoints.

My experiment also seemed to suggest that removing the barriers internal to blade had about a similar effect to the async compute^ for this workload, but having manual barriers is perhaps undesirable. Though, I could see a way for blade to expose it with encoder.set_use_auto_barriers(bool) and then a manual encoder.barrier(&self, src, dst). But if we need that ultimately for the game I don't know if it needs to be included in blade proper.

Also, for correctness of the simulation, I believe there has to be a buffer copy as well so that each compute task works on the resulting data of the most recent one

                if let mut transfer = self.compute_encoder.transfer("copy") {
                    let prev_compute_idx = draw_idx; // only one in flight atm

                    let a = &self.particle_systems[prev_compute_idx];
                    let b = &self.particle_systems[compute_idx];
                    // NOTE: an indirect_dispatch or at least just compute pass could copy only the alive particles..
                    transfer.copy_buffer_to_buffer(
                        a.particle_buf.at(0),
                        b.particle_buf.at(0),
                        a.particle_buf.size(),
                    );
                    transfer.copy_buffer_to_buffer(
                        a.free_list_buf.at(0),
                        b.free_list_buf.at(0),
                        a.free_list_buf.size(),
                    );
                }

Yeah, I'm not sure how I feel about skipping the barriers between passes. Something like this should be very explicit about what you are expecting to run at the same time. I'll think about it.

Yeah, I'm not sure how I feel about skipping the barriers between passes. Something like this should be very explicit about what you are expecting to run at the same time. I'll think about it.

Yeah the barriers was just an experiment on my part and not related really, though I did open #343 as we have a perhaps much more motivating example for custom barriers, or just a single little pass without an automatic barrier.

Interesting. So in this case multi-queue would not help you. I'm actually surprised you are seeing this much cost for the barriers.