Asynchronous Compute and Concurrent Graphics/Compute Pipeline Dispatch: Advanced Implementation and Real-World Architecture

[Jayden Carter]

I’ve been benchmarking concurrent dispatch patterns in Vulkan and I’m hitting diminishing returns when I try to overlap compute work with the rasterization stream on the same GPU. My setup uses separate command buffers submitted to independent queues, but I’m seeing pipeline stalls whenever the compute shader reads buffers that the graphics pass is actively writing. How are you handling the synchronization overhead between these streams without stalling the whole pipeline? Do you rely on explicit semaphores and fences, or have you found a way to use separate memory pools to minimize the dependency tracking?

For anyone running this in a real engine, what’s your strategy for avoiding pipeline bubbles during frame transitions? I’ve tried splitting the frame into compute-heavy and graphics-heavy subframes, but the scheduler overhead seems to eat the gains on lower-end hardware. Are there specific register pressure or occupancy thresholds you use to decide when concurrent dispatch actually pays off? And what benchmarking methodology are you using—GPU timeline queries, custom profilers, or something else—to measure the real-world improvement versus the theoretical speedup?

"Noctua NH-D15 chromax.black | Zero pump failure anxiety, whisper quiet"

[Grace Rogers]

Great topic. The key thing most people miss is that “asynchronous compute” means very different things depending on the silicon. On AMD’s GCN/RDNA family you get dedicated ACU hardware—separate ring buffers, instruction schedulers, and a portion of each compute unit that can process a compute shader while graphics work continues on the rest of the CU. That’s genuine hardware-level parallelism, not just scheduling overlap. NVIDIA takes a different route: compute and graphics share the same SMs without a dedicated async-compute partition, so you’re really getting temporal interleaving and better occupancy hiding rather than true

Battlestation:

"• Processor: i5-13600K"

"• Graphics: RX 7800 XT"

"• Memory: 32GB DDR5 6000MHz CL30"

[Blake Murphy]

Real talk on the implementation side: async compute only actually helps when your target GPU has spare execution units to run the compute work on while graphics is busy, and that’s a hardware-dependent thing, not a magic API toggle. On AMD’s GCN/RDNA architecture, the async compute feature works by routing compute work to the second SIMD engine of a compute unit while the graphics work occupies the first one—so you get genuine overlap only if the graphics shader isn’t already saturating both engines. If your fragment stage is the bottleneck, throwing a compute job onto the “async” queue just serializes behind it and you’ve added driver overhead for nothing. Vulkan’s model makes this explicit with queue families, but here’s the part most guides gloss over: having a dedicated compute queue doesn’t guarantee concurrency at all. You need to verify the queue family flags actually support graphics and compute overlap, and even then you’re at the mercy of the driver’s scheduler deciding whether it can interleave your submissions. I’ve benchmarked this on RDNA2 cards and the win is real but modest—single-digit percentage gains in compute-heavy titles like those using compute-based shadow or post-processing, and it can actively hurt if you’re already GPU-saturated at 1080p.

For the dispatch ordering, stop thinking of it as “fire both and hope for the best.” The practical architecture that actually pays off is to partition your frame into independent work

"Tekken 8 Tekken King | Leverless Arcade Controller (Qanba Obsidian Mod)"

[Author]

Posts