Not sure if this is something within your reach, but if possible I would suggest going the other way, ie. have your API expose a DX12-style PSO and emulate that on DX11. You can easily hash the DX11 rasterizer state, depth stencil state and blend state and only set them if they actually change. In my engine I always set the shaders and input layout on DX11 when switching PSO and it hasn't bitten me performance-wise yet at least. I would assume you could hash those too if you want, and only set them if they change. On DX12, setting the PSO is straightforward and Vulkan is pretty much the same if you want to go that route at some point.

1 hour ago, GuyWithBeard said:

Not sure if this is something within your reach, but if possible I would suggest going the other way, ie. have your API expose a DX12-style PSO and emulate that on DX11. You can easily hash the DX11 blend state, rasterizer state, depth stencil state and blend state and only set them if they actually change. In my engine I always set the shaders and input layout on DX11 when switching PSO and it hasn't bitten me performance-wise yet at least. I would assume you could hash those too if you want, and only set them if they change. On DX12, setting the PSO is straightforward and Vulkan is pretty much the same if you want to go that route at some point.

This is kind of what I do too, although I still have separate blend/raster/depth state objects, you have to build a PSO out of them to use them in a draw command. In D3D11 they actually hold the native state objects, and the PSO basically just holds a reference to them, this would turn around in the planned D3D12 implementation, where the separate state objects would only contain the descriptors, and the PSO would have the native stuff. It's kind of a mix of both worlds.

I've been there myself. I'm creating a library which is an abstraction layer for graphics APIs. So when I started the project I sat D3D11, D3D12 and Vulkan on a chair (each API in their own chair that is ;)) in the same table and asked them: "What are your common factors?"

The first answer was much like what you are trying to do now: A D3D11 like pipeline state manager. I actually did it, BUT, it was very inefficient. There were so many PSOs to be internally created, state changes that had to be track and the lookup was adding to latency. I worked with this model for some time but as the project grown I had to recall the APIs again and ask the same question again.

For the new answer I had to do as others suggested: I had to redesign my PSO common factor and went for a D3D12 like PSO manager. Literally I had to create an "IPipelineStateObject" interface. This new interface is natural for D3D12 and Vulkan to implement and is very easy for D3D11 to "emulate". This resulted in a much more native and efficient implementation.

Not only for PSO, but in general, if you try to get a common factor between all available APIs then you'll notice that the model leans towards a Vulkan like design.