Detect unused parameters/variables.

[obfuscate]

Is there a way in slang to detect that a parameter is unused in the final shader?
E.g. I have a header:

#pragma once

SamplerState g_samplerPointClamp;
SamplerState g_samplerPointWrap;

SamplerState g_samplerLinearClamp;
SamplerState g_samplerLinearWrap;

and I have a shader including this header:

const float3 albedo = g_albedo.SampleLevel(g_samplerLinearClamp, i.uv, 0.0f).rgb;

Is it possible to understand that 3 of 4 samplers unused?

[aidanfnv]

The best way to detect the unused parameters is to get the compiled shader's reflection data using Slang's reflection API, and then use some additional functions, namely IComponentType::getEntryPointMetadata(), to get metadata for the entry points in the reflections, and then you can search that metadata for usages of each parameter, checking with IMetadata::isParameterLocationUsed().
See the section "Determining Whether Parameters Are Used" in the chapter "Using the Reflection API" in the user guide for details on how you can do that.

Alternatively, for a simple shader, you could probably get away with compiling the shader with -reflection-json to dump the reflection info to a JSON file, and then looking through that file which will list the parameters and indicate which ones are used. As another alternative, you could try compiling with and without the -preserve-params option, which prevents Slang from doing dead code elimination on unused parameters, and compare the outputs, although that approach will only work for some targets and not others.

[obfuscate]

Thanks a lot, getEntryPointMetadata works fine for me!

[obfuscate]

@aidanfnv , sorry for bothering you, but I just realized one key moment:
Let's consider the example above: in that case each of sampler takes its own sampler register(from s0 to s3). The shader uses g_samplerLinearClamp which takes register s2. So, if I want to use DescriptorTable in a root signature, I'll have to allocate a descriptor range {baseShaderRegister = 0, numDescriptors = 4} (the simplest case. of course I may try to find gaps and subdivide ranges, but it sounds too complicated in terms of root signature). So, If I want to use different Descriptor Heaps: CPU-heapto store persistent descriptor handles and GPU-heap for transient per-frame descriptors; I will have to "sub-allocate" from the gpu-heap each time 4 descriptors and put at the 3rd slot a used sampler. It may lead to redundant overusage of the heap.
So, my question is: is it possible to somehow force slang shrink registers for unused parameters? If it is possible I'll would expect that register for g_samplerLinearClamp will be s0, not s2.

[aidanfnv]

That register assignment, while wasteful for your example, is an intentional design decision, mentioned in the "Getting Started" chapter in the user guide:

Slang provides a guarantee that all parameters will have fixed bindings regardless of shader optimization. Without generating explicit binding layout qualifiers, the downstream compiler in the driver may change the binding of a parameter depending on whether any preceding parameters are eliminated during optimization passes. In practice this causes a pain in application code, where developers will need to rely on run-time reflection to determine the binding location of a compiled shader kernel. The issue gets harder to manage when the application also needs to deal with shader specializations. Since Slang will always generate explicit binding locations in its output on all targets as if no parameters are eliminated, the user is assured that parameters always gets a deterministic binding location without having to write any manual binding qualifiers in the Slang code themselves.

That being said, to answer your question: No, Slang does not currently provide a way to be forced to shrink registers for unused parameters.

[obfuscate]

Aha, I see. Sounds sad, imo. Will be there a chance to get an opportunity to disable it by wish?

[gtong-nv]

Hi @obfuscate , Slang will not likely implement a feature to shrink registers for unused parameters in the foreseeable future, as this would conflict with its core design goals of deterministic binding and modular shader development