Jump to content
  • Advertisement
Sign in to follow this  

DX12 uber shader/ uber PSO management in DX12

This topic is 796 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey Guys,


I am currently working on a hobby project where I try to compare different dynamic volume rendering techniques and settings under DX12 framework. So in this project I have GUI to be able to switch different volume buffer types, different spacial data structures and different voxel data type (16bit, 32bit per channel) and enable/disable different features (compute iso surface normals for example), you can get the idea from the attached image.



However with that in mind I end up with lots of shaders and therefore lots of PSOs (basically the combination of almost all the features). Thus I have these ugly code:

    ComputePSO _cptUpdatePSO[ManagedBuf::kNumType][SparseVolume::kNumStruct];
    GraphicsPSO _gfxUpdatePSO[ManagedBuf::kNumType][SparseVolume::kNumStruct];
    GraphicsPSO _gfxVolumeRenderPSO[ManagedBuf::kNumType]
    GraphicsPSO _gfxISOSurfRenderPSO
    GraphicsPSO _gfxStepInfoPSO;...

so I managed with multi-dimension array of PSOs and the dimension will increase if more feature added. But I don't think this is the proper way of doing this kind of thing. 


I've heard in a typical game, you guys will have more than 30000+ shaders on the fly, so probably in development, you guys also need to face this same kind of situation where you have this PSO explosion, and I really appreciate it if someone could talk about how they deal with those shader/PSO management.



Share this post

Link to post
Share on other sites

Here's a list of the options that game engines generally use. Not every option is suited to every situation.


1. Compile every possible shader up front. This can generate lots of shaders. Ideally you'd only compile the variations that you know you actually need in the game.


2. Use conditionals within the shader code, based on values in constant buffers, to control some or more features. This will usually make the shaders slower to execute.


3. Combine multiple passes of a simple shader to get the complete end result. For example you could render an object once per light, with additive blending, to handle an arbitrary number of lights. This again will reduce performance compared to doing it in a single pass.


4. Compile the actual shader you need on the fly. This is a reasonable option for an editor where it doesn't matter too much if switching shader takes a few seconds. This can be combined with a cache of recently used shaders.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!