You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current shader implementations use a combination of runtime branching and preprocessor magic to compile the desired shader permutation required for rendering.
Typical uses of runtime branching are:
Fog mode - still not sure why I made this runtime
Alpha blending modes - for optimizing opaque data out of OIT buffer
Alpha rejection toggle, comparison mode
Texture stages et al.
Light enabled state, type (point, spot, directional)
To greatly reduce runtime branching, shader source code generation could be employed to generate task-optimized shaders that already understand these conditions.
These shaders need to be uniquely and reliably identifiable at runtime. This is currently handled with a huge 64-bit bitfield. By taking runtime checks and making them shader permutations, we exhaust the number of reasonable bits we can use in that bitfield. An optimized multiple-key lookup mechanism might be a good idea (conceptually, std::unordered_map<bitfield_a, std::unordered_map<bitfield_b, shader>>).
I'd like this done in such a way that snippets of shader code--which would be used to produce full shaders--can be modified and re-loaded at runtime for rapid iteration.
The text was updated successfully, but these errors were encountered:
Current shader implementations use a combination of runtime branching and preprocessor magic to compile the desired shader permutation required for rendering.
Typical uses of runtime branching are:
To greatly reduce runtime branching, shader source code generation could be employed to generate task-optimized shaders that already understand these conditions.
These shaders need to be uniquely and reliably identifiable at runtime. This is currently handled with a huge 64-bit bitfield. By taking runtime checks and making them shader permutations, we exhaust the number of reasonable bits we can use in that bitfield. An optimized multiple-key lookup mechanism might be a good idea (conceptually,
std::unordered_map<bitfield_a, std::unordered_map<bitfield_b, shader>>
).I'd like this done in such a way that snippets of shader code--which would be used to produce full shaders--can be modified and re-loaded at runtime for rapid iteration.
The text was updated successfully, but these errors were encountered: