Problem
Currenly, each permutation is calculated with a selection of defines values. Each define must be specified with its accepted values for the shader to be compiled with. When the application requests a permutation, it must provide every define with its values. It means that when an additional define is introduced in the shader, not only the config must be updated (which is pretty logical), but every part of that application that is requesting any permutation of that shader must also be updated to include the additional define with a value, or else, no permutation will be returned; because after adding it, every permutation header includes the new define and if the app doesn't include the new one in the request, it will match with none of the permutations.
Proposed Solution
Adding support for optional defines; for instance:
TestShader.hlsl -T vs -E VSMain -D PERMUTATION_B={0,1} -D PERMUTATION_A={,1}
This indicates that PERMUTATION_A might be defined with value 1 or not be defined at all. While this is backward compatible, it makes it possible for the application to request a permutation with newly added define, which older parts of the application don't have to know about and hence don't need to add it for requesting a permutation.
Example:
Now
- Shader config before a feature:
TestShader.hlsl -T vs -E VSMain -D PERMUTATION_A={0,1}
- Permutations that application requests
{PERMUTATION_A=0} and {PERMUTATION_A=1}
- Shader config after adding a feature:
TestShader.hlsl -T vs -E VSMain -D PERMUTATION_A={0,1} -D PERMUTATION_B={0,1}
- Permutations that application requests
{PERMUTATION_A=0, PERMUTATION_B=0} and {PERMUTATION_A=1, PERMUTATION_B=0} and {PERMUTATION_A=1, PERMUTATION_B=1} (Older parts of code are also updated even though they don't use the new feature)
With the proposed solution
- Shader config before a feature:
TestShader.hlsl -T vs -E VSMain -D PERMUTATION_A={0,1}
- Permutations that application requests
{PERMUTATION_A=0} and {PERMUTATION_A=1}
- Shader config after adding a feature:
TestShader.hlsl -T vs -E VSMain -D PERMUTATION_A={0,1} -D PERMUTATION_B={,1}
- Permutations that application requests
{PERMUTATION_A=0} and {PERMUTATION_A=1} and {PERMUTATION_A=1, PERMUTATION_B=1} (Older parts of code was not updated because they don't use the new feature)
Implementation Obstracle
I started to implement the feature on a fork to make a pull request by myself. The only problem is that is some cases there are no defines specified:
TestShader.hlsl -T vs -E VSMain -D PERMUTATION_A={,1} -D PERMUTATION_B={,1}
Produces:
{}
{PERMUTATION_B=1}
{PERMUTATION_A=1}
{PERMUTATION_A=1, PERMUTATION_B=1}
The first permutation is not accepted by the rest of the code, and it produces an error that says: "The blob has no definitions.". I needed to know the design behind it and the reason that error check was put there to start implementing a workaround. I welcome any insights and ideas!
Problem
Currenly, each permutation is calculated with a selection of defines values. Each define must be specified with its accepted values for the shader to be compiled with. When the application requests a permutation, it must provide every define with its values. It means that when an additional define is introduced in the shader, not only the config must be updated (which is pretty logical), but every part of that application that is requesting any permutation of that shader must also be updated to include the additional define with a value, or else, no permutation will be returned; because after adding it, every permutation header includes the new define and if the app doesn't include the new one in the request, it will match with none of the permutations.
Proposed Solution
Adding support for optional defines; for instance:
TestShader.hlsl -T vs -E VSMain -D PERMUTATION_B={0,1} -D PERMUTATION_A={,1}This indicates that
PERMUTATION_Amight be defined with value1or not be defined at all. While this is backward compatible, it makes it possible for the application to request a permutation with newly added define, which older parts of the application don't have to know about and hence don't need to add it for requesting a permutation.Example:
Now
TestShader.hlsl -T vs -E VSMain -D PERMUTATION_A={0,1}{PERMUTATION_A=0}and{PERMUTATION_A=1}TestShader.hlsl -T vs -E VSMain -D PERMUTATION_A={0,1} -D PERMUTATION_B={0,1}{PERMUTATION_A=0, PERMUTATION_B=0}and{PERMUTATION_A=1, PERMUTATION_B=0}and{PERMUTATION_A=1, PERMUTATION_B=1}(Older parts of code are also updated even though they don't use the new feature)With the proposed solution
TestShader.hlsl -T vs -E VSMain -D PERMUTATION_A={0,1}{PERMUTATION_A=0}and{PERMUTATION_A=1}TestShader.hlsl -T vs -E VSMain -D PERMUTATION_A={0,1} -D PERMUTATION_B={,1}{PERMUTATION_A=0}and{PERMUTATION_A=1}and{PERMUTATION_A=1, PERMUTATION_B=1}(Older parts of code was not updated because they don't use the new feature)Implementation Obstracle
I started to implement the feature on a fork to make a pull request by myself. The only problem is that is some cases there are no defines specified:
TestShader.hlsl -T vs -E VSMain -D PERMUTATION_A={,1} -D PERMUTATION_B={,1}Produces:
{}{PERMUTATION_B=1}{PERMUTATION_A=1}{PERMUTATION_A=1, PERMUTATION_B=1}The first permutation is not accepted by the rest of the code, and it produces an error that says: "The blob has no definitions.". I needed to know the design behind it and the reason that error check was put there to start implementing a workaround. I welcome any insights and ideas!