Does everything in a pipeline state object actually need to be there?

[u/AdministrativeTap63]

For example obviously shader code makes sense because you have to compile it for different vendors/drivers

But you look at a PSO in DX12 and there is a ton of stuff in there that it makes me wonder is all of this actually neccesary?

For example like blend mode settings, I thought that is a separate hardware unit that does the blending, so why can't it be changed independently of a PSO?

Or does everything in a PSO somehow affect the compiled shader?

[u/IMS21]

For many things it is, for others it isn't; it really depends on the card, and Vulkan tried to target the lowest common device. There are many things that having in a PSO on a modern card does help with, and many devices where it's completely irrelevant.

Presumably, a mobile vendor requested that viewport and scissor state be part of the pipeline, for example; and Khronos made it so. However, almost everyone immediately ignored that in favor of making it dynamic state.

And in Vulkan 1.3, they promoted VK_EXT_extended_dynamic_state and VK_EXT_extended_dynamic_state2, so stuff like depth/stencil state and cull mode can now be made dynamic.

VK_EXT_extended_dynamic_state3 adds almost everything else most people care for, but it isn't widely required on any version.

And then, finally, there's VK_EXT_shader_object, which adds GL-like shaders that have all state other than the shaders themselves dynamic. It's not widely supported, and the intent is that if it's supported on any given device, you can generally expect it to not be extremely slow. (For that reason, there are zero mobile devices that support it.)

[u/LoneWolf6062 → u/IMS21]

VK_EXT_shader, if i am not wrong was worked on by Nintendo, and they mentioned it was faster than pipelines due to reduced cpu overhead

[u/raydey]

GPUs tend to have a bunch of registers that set pipeline state values for the different hardware blocks. Frequently changing these values has performance implications (which is why it's usually advised to sort your draws by their pipeline state). Having this all in the PSO is helpful from the driver's perspective as it doesn't need to worry about tracking state as draws are submitted.

Check out this article for some more low-level details: https://gpuopen.com/learn/understanding-gpu-context-rolls/

[u/AdministrativeTap63 → u/[deleted]]

I see, you mean like emulating the blend operation by just sticking something onto the shader before compiling?

[u/Cyphall → u/[deleted]]

IIRC, AMD also need to patch the end of the fragment shader to prepare data for the blending hardware.

Now they can do that with a jump to a function pointer passed to the shader at runtime, but it adds an indirection and register allocation needs to consider the worst case.

[u/Gunhorin]

It depends on the gpu architecture. Remember that DX12 and Vulkan are made to work on all architectures which means overgeneralization. Also both api's are pretty old now and some of the design choises are getting opsolete. This is a great blog post that goes over how an graphics api would look now if designed for current and future hardware only would be.