Skip to content

Support for permutation with no repetition #11

Description

@MohammadMDSA

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!

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions