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)"
