Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NZSLC: Add precompiled binaries for options #18

Open
SirLynix opened this issue Jun 23, 2022 · 0 comments
Open

NZSLC: Add precompiled binaries for options #18

SirLynix opened this issue Jun 23, 2022 · 0 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@SirLynix
Copy link
Contributor

One drawback of NZSL is its massive use of options, which prevent the early generation of GLSL and SPIR-V.

Something we could do to help with this is to give NZSLC (compiler) a set of options values that could be precompiled and embedded into a file (.nzslb? another file?).

For example:

[nzsl_version("1.0")]
module;

option HasDiffuseTexture: bool = false;
option HasAlphaTexture: bool = false;
option AlphaTest: bool = false;

option PosLocation: i32;
option UvLocation: i32 = -1;

We could imagine an additional file giving all options values to precompile:

{
    "targets": [
        {
            "type": "glsl",
            "version": 330
        },
        {
            "type": "glsl-es",
            "version": 330
        },
        {
            "type": "spv",
            "version": 100
        }
    ],
    "option_values": {
        "HasDiffuseTexture": [false, true],
        "HasAlphaTexture": [false, true],
        "AlphaTest": [false, true]
    },
    "variants": [
        {
            "options": {
                "ColorLocation": 0,
                "UvLocation": 1
            }
        },
        {
            "options": {
                "ColorLocation": 1,
                "UvLocation": 0
            }
        }
    ]
}

this would lead to the generation of 16 variations per shading language (so a total of 48 here), each variation would be associated with a hash of its option values.

Perhaps we could also give options a range of acceptable values:

[range(0,1)] option PosLocation: i32;
[range(0,1)] option UvLocation: i32 = -1;

which would allow NZSLC to know which variations are allowed without even a variant list file (however this could result in a lot of variations very quickly).

What do you think?

@SirLynix SirLynix added enhancement New feature or request question Further information is requested labels Jun 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant