GLSL to Slang Questions

[LouChiSoft]

Hi, I'm converting some GLSL code to Slang (and them compiling it back out to GLSL for comparison). I have a very basic GLSL shader that looks like this:

#[compute]
#version 450

layout(std430, binding = 0) buffer buffer_t {
    float _data[];
} data;

layout(local_size_x_id = 0, local_size_y_id = 1, local_size_z = 1) in;
void main()
{
    uint index = gl_GlobalInvocationID.x + (gl_WorkGroupSize.x * gl_GlobalInvocationID.y);
    data._data[index] = data._data[index] * 5;
    return;
}

Most of the conversion is straight forward but I have ran into two issues so far that I can't seem to find an answer on:

• Issue 1 is how do you define a specialisation constant in Slang? As you can see in the example above I use specialisation constants to decide the size of the workgroup at runtime, but so far I have only been able to get compile time sizes working in Slang.
• Issue 2 is that WorkGroupSize() doesn't appear to work. Whenever I try to use it I get unimplemented feature in Slang compiler. I assume that means that it doesn't work for the GLSL backend, is there an alternative?

Slang version for reference:

RWStructuredBuffer<float> data;

[shader("compute")]
[numthreads(5, 2, 1)]
void computeMain(uint3 threadId: SV_DispatchThreadID)
{
    int3 size = WorkgroupSize();
    uint index = threadId.x + (size.x * threadId.y);
    data[index] = data[index] * 5;
}

[jkwak-work]

@ArielG-NV for visibility regarding WorkgroupSize()

[ArielG-NV]

WorkgroupSize() should work, this is a bug. The bug is likely introduced by #3925. What I believe is happening is we don't actually replace the kIROp_GetWorkGroupSize intrinsic with a constant correctly (bug in materializeGetWorkGroupSize), this causing an invalid intrinsic to reach the code emitting stage.

I will make an issue to track this shortly.

[jkwak-work]

I created an issue #4504

[ArielG-NV]

Thank-you for making the issue

[ArielG-NV]

#4505 should address+solve the WorkgroupSize() issue.

[LouChiSoft]

I read through the comment above. Glad the workgroup issue could be fixed. Don't suppose there is any information about specialisation constants? The only reference I could find was #3044 from over 6 months ago that says the feature was dropped. Is this still the most up to date state of the feature?

[csyonghe]

We still don't have direct support for specialization constants at this time. The closest thing we have is slang's link time specialization as documented in this page: https://shader-slang.com/slang/user-guide/link-time-specialization.html

Since specialization is done at slang IR level, it will provide consistent behavior across all platforms.

[csyonghe]

Is specialization constant support a blocker for you to adopt Slang?

[LouChiSoft]

Right now my use case for Slang is feasability research. I want to see how easy it is to write an addon for the Godot game engine to enable Slang shaders instead of GLSL. If it works well I want to at least be able to support the features that Godot currently supports which includes specialisation constants.

[csyonghe]

Got it. We are interested in your findings. Feel free to let us know if you find any other issues, and if you would like us to prioritize for specialization constants.

[csyonghe]

Specialization constants are now supported by the compiler.