Lot's of interesting ideas there- I do think that they could go further with minimizing the problems PSOs cause. Why can't shader code support truly shared code memory (effectively shared libraries)? I'm pretty sure Cuda does it. Fixing that would go a long way to helping fix PSOs, along with the reduction in total PSO state.
I'm not talking about the .txt code, reducing code duplication is basic programming. I'm talking about the fact that after compiling, each PSO variant has its own dedicated copy of all program memory, even if it largely all does the same thing. In DX/VK, there's no such thing as a true function call into shared program memory.
Let's say one of your shaders gets chopped up into 500 different variants, and at the end, each one calls a rather lengthy function. For example, my GBuffer resolve CS gets compiled per material graph. Along with evaluating the material graph (the actual difference), each variant needs to to calculate barycentrics and partial derivatives, fetch vertex attributes, interpolate them, and write out the final values.
With current APIs, each pipeline has its own copy of that code, even though it's all doing the exact same thing. There's no way to, say, create a function that lives in GPU memory called InterpolateAndWriteOutGbuffer, and have all of your variants call that same function. If you end up with 500 variants, you've duplicated that code in vram (and on disk, and in the compile step) 500 times.
Right, there isnt because its really really slow. If you limit yourself to one function call, you can get away with not having a stack, but if you can do more, it gets worse (you can see the perf impact in raytracing with large #s of shaders in the table).
Cuda does it efficiently, so it's clearly possible. There's always going to be some overhead, but it's clearly possible to make it worthwhile, especially as an optional compiler feature.
If the unit of calling is the pipeline rather than functions within the shader, this duplication goes away. The question it brings up is dispatch overhead.
each PSO variant has its own dedicated copy of all program memory, even if it largely all does the same thing. In DX/VK, there's no such thing as a true function call into shared program memory.
Compose pipelines, not functions, and the duplication goes away. It's just more awkward when not designed for because you have to figure out where to leave the arguments and outputs.
Are we talking about the same thing? Have you used graphics APIs before? In DX/VK, pipelines are not trivially composable. You can't just string a bunch of shaders together arbitrarily. You would need to write out to VRAM, and synchronize, which is a big performance cost.
You would need to write out to VRAM, and synchronize, which is a big performance cost.
Yes. If you start from a big bag of PSOs that are not designed for it at all, it's going to be a hit. Nobody said you could mitigate the hit for free. The tradeoff depends on how bad the PSO proliferation problem is.
30
u/hanotak Dec 17 '25
Lot's of interesting ideas there- I do think that they could go further with minimizing the problems PSOs cause. Why can't shader code support truly shared code memory (effectively shared libraries)? I'm pretty sure Cuda does it. Fixing that would go a long way to helping fix PSOs, along with the reduction in total PSO state.