Change set order of imported and local ParameterBlocks on slangc?

[papasitopapi]

Hi,

I posted this on the discord, but I figured maybe here it would get more visibility.

Currently, giving this input to slangc:

module Module;

ParameterBlock<float> moduleParameter1;
ParameterBlock<float> moduleParameter2;

// Shader.slang
import Module;

ParameterBlock<float> shaderParameter1;
ParameterBlock<float> shaderParameter2;

[shader("compute")]
[numthreads(32, 1, 1)]
void main(ParameterBlock<float> entryParameter1, ParameterBlock<float> entryParameter2) {}

COMMAND slangc Shader.slang
               -target spirv
               -profile spirv_1_4
               -emit-spirv-directly
               -fvk-use-entrypoint-name ${ENTRY_ARGS}
               -reflection-json ${REFLECTION_FILE}
               -dump-ast
               -o ${SPIRV_FILE}

Produces these global parameter bindings on the reflection JSON:

"bindings": [
    {
        "name": "shaderParameter1",
        "binding": {"kind": "subElementRegisterSpace", "index": 0, "used": 0}
    },
    {
        "name": "shaderParameter2",
        "binding": {"kind": "subElementRegisterSpace", "index": 1, "used": 0}
    },
    {
        "name": "moduleParameter1",
        "binding": {"kind": "subElementRegisterSpace", "index": 2, "used": 0}
    },
    {
        "name": "moduleParameter2",
        "binding": {"kind": "subElementRegisterSpace", "index": 3, "used": 0}
    }
]

I would like to change the bindings so that the imported parameters are assigned first over the locally declared ones. If I'm reading the docs correctly, it should be possible to do it through the compilation API:

Second, all global-scope parameters without manual annotations claim ranges using a first-fit allocation. The relative order in which modules and source files are visited is deterministic, but dependent on what was passed to the linker. Within a single file parameters are visited top-down in source order.

But I would rather not go into the API at this time. Is there a way to do it through slangc? Preferably without having to manually add explicit bindings to the parameters.

Thanks

[tangent-vector]

I completely understand where you’re coming from with this request, but I’m wary of keeping on piling more complexity (options, flags, etc.) on top of slangc.

For folks who are reluctant to switch to using the compilation API, I’d be interested to know: what are the sticking points that make you reluctant? If we provided something like a high-quality Python API that could be used to orchestrate Slang compilation, would that change anything?

On the specific topic at hand, my honest answer is that the best way to address the problem is to switch away from pervasive use of global-scope shader parameters declared in modules that get imported. In practice, global-scope shader parameters are akin to global variables or singletons: usually an anti-pattern or “code smell,” unless clearly justified.

You can get better control over the exact layout of things by either declaring all the parameter blocks you want as entry-point parameters, or by declaring them at global scope… but only in the same modules that directly declare the entry points (and which are not imported anywhere else).

[papasitopapi]

You can get better control over the exact layout of things by either declaring all the parameter blocks you want as entry-point parameters, or by declaring them at global scope… but only in the same modules that directly declare the entry points (and which are not imported anywhere else).

That does make a lot more sense. I was doing the module declaration as a workaround for something else and I was tunnel visioning into it after it stopped being relevant. Thanks!

For folks who are reluctant to switch to using the compilation API, I’d be interested to know: what are the sticking points that make you reluctant?

I'm new to graphics as a whole, so currently I'm just exploring ways to do things. I do assume I will want to use the APIs at some point, but the convenience of slangc and the reflection json seems like the correct approach, for now.

I will say that I when I gave the API guide a quick look over, the thing that immediately made engaging with it seem like a problem better suited for future me was being presented with the Slang namespace, the slang namespace, and the Slang prefix:

using namespace slang;

Slang::ComPtr<IGlobalSession> globalSession;
SlangGlobalSessionDesc desc = {};
createGlobalSession(&desc, globalSession.writeRef());

Probably compounded by my unfamiliarity with COM objects, but still.

Edit: I reread my comment and I feel like I left my point dangling there. What I meant is that what I perceived as a convoluted namespace structure (in addition to no documentation outside of the user guide, I would like to add now) gave me the impression of a similarly difficult to work with API, and made getting straight into it seem like a worse choice compared to the simpler command line tool.

[juliusikkala]

I'm also one of those people who don't like using the API. I'm also kind of allergic to the COM API, it just feels needlessly complicated to me and I'm also not super comfortable with COM due to coming from a more unix-y, linux-y background.

There are no (up-to-date) C bindings, limiting the usability of the Slang API to just C++ programs unless you're willing to make bindings yourself. Almost all programming languages have some level of C FFI or automatic binding generation support for C, but similar support for C++ is much more rare. Also, this means that I can't use the Slang API from CPU-side Slang code 😭 (but I'm fully aware that that use case is uncharted territory right now).

In general, I like to compile all of my shaders (incl. permutations) ahead of time as a build step in CMake, and slangc makes build system integration easy. I want to treat shader code as if it was normal code that is built in a build system just like everything else is.

• My "hot reloading" is just system("cmake --build " BUILD_DIRECTORY " shaders") and reloading pipelines whose SPIR-V got touched in that process 😄
• For permutations, I use either SPIR-V specialization constants or generate the necessary permutations ahead of time with compiler options
• For reflection, I use spirv-reflect, not Slang's own reflection.

These choices allow me to easily change compilers and shading languages if I wish to do so, or even mix multiple languages! I had this workflow with GLSL and don't want to change it because it served me well (making the transition to Slang easier). Of course, this workflow is pretty specific to SPIR-V. I think I would definitely have to use the Slang API somehow if I wanted to target multiple graphics APIs.