Small one to fix ARM64 not being detected correctly for MSVC building for windows ARM64.

Would be awesome to see windows arm64 binaries attached to releases as well, but I wasn't sure what needed to change to make that happen.

This may or may not be an issue of Slang, but I have observed a strange performance issue in my shader that is probably worth noting here.

On Vulkan, I defined a uniform float4x4 array in my shader code (in this case, the lightMatrix for cascaded shadow maps), and as long as I am accessing the array in a loop, the performance drops dramatically (from ~200fps to 20fps), even after I changed loop to do nothing else but accessing the data.

The performance issue is solved by manually unrolling the loop, and make sure the shader is only using constants as indices into the array. I also tried to just define float4 arrays, and construct a float4x4 by manually loading 4 float4s, but that doesn't seem to work either. However, the same issue does not exist for float4x3 arrays.

Note that it does not matter whether the code is actually executed or not, the existence of such code causes the slow down of entire pixel shader execution, even if the access is in a branch that is never executed.

I feel that this may have something to do with row_major, and if that is the case, then we definitely should generate code to handle all input fetching ourselves (as we discussed last time).

Hi,

I was trying slang for a while and noticed for SPIRV (and GLSL) the ParameterBlock is converted to a uniform with set=1 decorator. Shouldn't that be set=0?

Input: shader.slang:

struct UBOData {
    float4x4 model;
    float4x4 view;
    float4x4 proj;
};

ParameterBlock<UBOData> ubo;

GLSL output:

layout(binding = 0, set = 1)
layout(std140) uniform _S1
{
    UBOData_0 ubo_0;
};

Shouldn't set be 0? Same with SPIRV's disassembly: OpDecorate %_ DescriptorSet 1

I am trying to run some vulkan code, and my pipeline layout has only 1 descriptor set which is set 0. Is there any specific reason to go with set 1?

Ran on Slang binary: v0.10.32

Proposing the following API:

struct Value
{
    int valueType;
    char * stringValue;
    int intValue;
    float floatValue;
};
struct EntryPointSet
{
     const char * name;
     SlangProfileID vsProfile, psProfile, hsProfile, gsProfile, dsProfile;
     int specializationArgumentCount;
     Value ** arguments;
};
int spAddEntryPointSet(compileRequest, EntryPointSet entryPointSet);

SLANG_API char const* spGetEntryPointSetSource(
        SlangCompileRequest*    request,
        int                     entryPointSetIndex,
        SlangStage       stage);

SLANG_API char const* spGetEntryPointSetCode(
        SlangCompileRequest*    request,
        int                     entryPointSetIndex,
        SlangStage       stage);

When a compile request gets executed, it will compile the entry points defined in an entry point set using the corresponding profiles. The compiled code can be retrieved via spGetEntryPointSetSource and spGetEntryPointSetCode functions. spGetEntryPointSetSource returns null if the corresponding stage is not defined by the entry point set.

Vector comparison operators such as operator ==(float3, float3) should return bool3, which shouldn't be allowed directly as if condition or in branching(x?y:z) expressions.

Currently Slang does not issue any diagnostic message when source code does this, and generates invalid HLSL/GLSL that fails downstream compilation.

Hi, In slang shader I write:

float computeRoot(float b, float c, int2 uv)
{
    float d = b * b - 4 * c;
    gDebugTexture[uv] = float4(b*b,4*c,d,0);
    return d;
}

upon inspecting in renderdoc, the input of b = 0.016f; c = 0.00006f; I would expect b*b = 0.000256f, 4 * c = 0.00024, and d = 0.000016f; But in renderdoc it actually shows that gDebugTexture[uv] = ( 0.00026, 0.00026, 0, 0). Which means that b*b is calculated into 0.00026 with the same value as 4 * c becoming 0.00026. In turns the d becomes 0.

This doesn't seems to be executing at 32 bit floating point precision. Looks more like half floating point precision. If I look at the spir-v code in renderdoc, i don't see any converting into half floating point.

Any idea why this is happening?

thanks.

//TEST(compute):COMPARE_COMPUTE:-xslang -use-ir
//TEST_INPUT:ubuffer(data=[0 0 0 0], stride=4):dxbinding(0),glbinding(0),out
//TEST_INPUT:type AssocImpl


RWStructuredBuffer<float> outputBuffer;

interface IBase
{
    float getVal();
};

interface IAssoc
{
    associatedtype TBase : IBase;
};

struct BaseImpl : IBase
{
    float getVal() { return 1.0; }
};

struct AssocImpl : IAssoc
{
    typedef BaseImpl TBase;
};

__generic_param T : IAssoc;


[numthreads(4, 1, 1)]
void computeMain(uint3 dispatchThreadID : SV_DispatchThreadID)
{
    uint tid = dispatchThreadID.x;
    T.TBase base;
    float rs = base.getVal();
    outputBuffer[tid] = rs;
}

Output HLSL contains FuncType = /*unhandled case*/

To express entry point functions in a entry-point-set struct, we need to be able to define the entry point functions as static methods of a struct type.

For example, we should be able to compile:

struct EPS
{
      static VSOut vsMain(VSIn vsIn) {}
      static FSOut fsMain(VSOut vsOut) {}
};

To support OpenGL applications, Slang needs to have a story for generating GLSL bindings of separate texture / sampler objects.

While it is relatively easier to just add support for combined texture/sampler objects for all targets, it feels limiting since it forces developers who wish to target OpenGL to author shader code using only combined texture/samplers.

Ideally, I should be able to write the following code:

Texture2D tex1;
Texture2D tex2;
SamplerState samplerState;

void func()
{
    vec4 v1 = tex1.Sample(samplerState, uv);
    vec4 v2 = tex2.Sample(samplerState, uv);
}

Slang should generate the following GLSL:

layout(binding = 0) sampler2D tex1;
layout(binding = 1) sampler2D tex2;
...

And provide the following reflection data:

tex1: type = texture2D,  binding = 0
tex2: type = texture2D, binding = 1
samplerState: type = sampler, binding = {0, 1} // this sampler is used at texture unit 0 and 1

There is one case that we cannot easily handle: when the shader code samples one Texture2D object with two different sampler objects, it actually needs two different sampler2D declarations in GLSL, and need to tell the host to setup two different combined texture/samplers and bind them to the pipeline. I don't see a easy way to do this without adding complexity to the reflection API and the host logic. So it might be helpful for the compiler to just emit error message when this happens.

The documentation for loadModule() states:

Executing loadModule("MyShaders") in host C++ code is similar to using import MyShaders in Slang code. The session will search for a matching module (usually in a file called MyShaders.slang) and will load and compile it (if it hasn’t been done already).

Now I'm trying to create an interface and place a struct conforming to that interface in a different (potentially generated) file, and load it with loadModule(). I have created a sample reproducing the issue:

Mat.slang:

interface IMaterial
{
    float4 sample(float2 texCoord);
}

ParameterBlock<IMaterial> gMaterial;

Simple.slang:

import Mat;

struct SimpleMaterial : IMaterial
{
    float4 sample(float2 texCoord)
    {
        return float4(1, 0, 1, 1);
    }
}

shaders.slang

import Mat;

[shader("fragment")]
float4 fragmentMain(float2 texCoord)
{
    return gMaterial.sample(texCoord);
}

main.cpp

#include <slang.h>
#include <slang-com-ptr.h>
#include <map>
#include <array>

struct ShaderCreateInfo
{
    std::string mainModule;
    std::vector<std::string> additionalModules;
    std::string name; // Debug info
    std::string entryPoint;
    std::vector<const char*> typeParameter;
    std::map<const char*, const char*> defines;
};

int main()
{
    ShaderCreateInfo createInfo =
    {
        .mainModule = "shaders.slang",
        .additionalModules = { "Simple" },
        .name = "TestCompile",
        .entryPoint = "fragmentMain",
        .typeParameter = { "SimpleMaterial" }
    };

    thread_local Slang::ComPtr<slang::IGlobalSession> globalSession;
    if(!globalSession)
    {
        slang::createGlobalSession(globalSession.writeRef());
    }
    slang::SessionDesc sessionDesc;
    sessionDesc.defaultMatrixLayoutMode = SLANG_MATRIX_LAYOUT_COLUMN_MAJOR;
    sessionDesc.flags = 0;
    std::vector<slang::PreprocessorMacroDesc> macros;
    for(auto define : createInfo.defines)    
    {
        macros.push_back(slang::PreprocessorMacroDesc{
            .name = define.first,
            .value = define.second
        });
    }
    sessionDesc.preprocessorMacroCount = macros.size();
    sessionDesc.preprocessorMacros = macros.data();
    slang::TargetDesc vulkan;
    vulkan.profile = globalSession->findProfile("glsl_vk");
    vulkan.format = SLANG_SPIRV;
    sessionDesc.targetCount = 1;
    sessionDesc.targets = &vulkan;
    std::array<const char*, 3> searchPaths = {"shaders/", "shaders/lib/", "shaders/generated/"};
    sessionDesc.searchPaths = searchPaths.data();
    sessionDesc.searchPathCount = searchPaths.size();

    Slang::ComPtr<slang::ISession> session;
    globalSession->createSession(sessionDesc, session.writeRef());

    Slang::ComPtr<slang::IBlob> diagnostics;
    std::vector<slang::IComponentType*> modules;
    Slang::ComPtr<slang::IEntryPoint> entrypoint;

    for (auto moduleName : createInfo.additionalModules)
    {
        modules.push_back(session->loadModule(moduleName.c_str(), diagnostics.writeRef()));
        if(diagnostics)
        {
            std::cout << (const char*)diagnostics->getBufferPointer() << std::endl;
        }
    }
    slang::IModule* mainModule = session->loadModule(createInfo.mainModule.c_str(), diagnostics.writeRef());
    modules.push_back(mainModule);

    if(diagnostics)
    {
        std::cout << (const char*)diagnostics->getBufferPointer() << std::endl;
    }
    mainModule->findEntryPointByName(createInfo.entryPoint.c_str(), entrypoint.writeRef());
    modules.push_back(entrypoint);

    Slang::ComPtr<slang::IComponentType> moduleComposition;
    session->createCompositeComponentType(modules.data(), modules.size(), moduleComposition.writeRef(), diagnostics.writeRef());
    if(diagnostics)
    {
        std::cout << (const char*)diagnostics->getBufferPointer() << std::endl;
    }

    //slang::ProgramLayout* reflection = moduleComposition->getLayout(0, diagnostics.writeRef());
    //if(diagnostics)
    //{
    //    std::cout << (const char*)diagnostics->getBufferPointer() << std::endl;
    //}
    //std::vector<slang::SpecializationArg> specialization;
    //for(auto typeArg : createInfo.typeParameter)
    //{
    //    specialization.push_back(slang::SpecializationArg::fromType(reflection->findTypeByName(typeArg)));
    //}
    //Slang::ComPtr<slang::IComponentType> specializedComponent;
    //moduleComposition->specialize(specialization.data(), specialization.size(), specializedComponent.writeRef(), diagnostics.writeRef());
    //if(diagnostics)
    //{
    //    std::cout << (const char*)diagnostics->getBufferPointer() << std::endl;
    //}
    Slang::ComPtr<slang::IBlob> kernelBlob;
    moduleComposition->getEntryPointCode(
        0,
        0,
        kernelBlob.writeRef(),
        diagnostics.writeRef()
    );
    if(diagnostics)
    {
        std::cout << (const char*)diagnostics->getBufferPointer() << std::endl;
    }
    return 0;
}

Running this gives me the following error

shaders/Mat.slang(1): error 50100: No type conformances are found for interface 'IMaterial'. Code generation for current target requires at least one implementation type present in the linkage. interface IMaterial ^~~~~~~~~

Notice that the code for creating a specialized Component is commented out, as it gives me different error:

(0): error 38025: expected 0 specialization arguments (1 provided)

This hints that the ParameterBuffer is not recognized as a type parameter so I tried explicitly introducing it in Mat.slang:

type_param TMaterial : IMaterial;
ParameterBuffer<TMaterial> gMaterial;

This still gives the error about no specialization arguments being expected, and crashes the kernel code generation entirely at lowerCallToInterfaceMethod() in file slang-ir-lower-generic-call.cpp:285

I guess I'm using the API incorrectly, so help would be much appreciated. Thanks in advance.

Added support for multiple blocks resulting from conditional control flow. Restructured the unzip and transposition passes to achieve this.

The current strategy is to create a uint 'control' variable for every block that holds an index identifying the previous executed block. The primal blocks assign the appropriate index (which is then checked by the reverse-mode differential blocks)

For now, we only support IRIfElse, but support can be extended for switch-case statements.

Also fixed minor issues with the intermediates-splitting logic that arose as a result of multiple blocks.

Note! This may/may not be a problem in current Slang, but can be shown on 0.24.20 in shader playground

Take the following code...

RWStructuredBuffer<float> outputBuffer;

interface IA
{
    int doThing(int a);
};

interface IB : IA
{
    int anotherThing(int a);
};

struct Struct : IB
{
    int doThing(int a) { return a + 1; }
    int anotherThing(int a) { return a * a; }
};

int doThing<B : IB>(B b, int c)
{
    return b.doThing(c) + b.anotherThing(c);
}

[numthreads(4, 1, 1)]
void computeMain(uint3 dispatchThreadID : SV_DispatchThreadID)
{
	uint tid = dispatchThreadID.x;

    Struct s;
    int v = doThing(s, int(tid));
    
	float inVal = float(tid + v);

	outputBuffer[tid] = inVal;
}

Will cause an internal error with

(0): error 99999: Slang compilation aborted due to an exception of class Slang::InternalError: assert failure: The key does not exists in dictionary.

It may(?) be of interest that if you replace

int doThing<B : IB>(B b, int c)

with

int doThing(IB b, int c) 

Then compilation completes without problem.

Note: have confirmed the problem occurs on 0.24.8 where the problem was originally reported.

WIP: I think there are still a few in *.meta.slang that my awk script didn't catch.

Besides the noise the changes are in:

• source/slang/slang-emit-spirv.cpp
• tools/slang-lookup-generator/lookup-generator-main.cpp (This is a small program which extracts the spirv (or extinst) opnames from the json files in spirv-headers and generates a lookup table for them).
• premake5.lua

Hi, I am moving code from a DXC compiled base to Slang. I ran into the following problems making porting the shader code an issue for code readability.

1. struct forward declarations not working
2. non-inline method definitions are not working

The following is valid DXC code that does not compile using Slang:

struct PSInput
{
	float4 color : COLOR;
};

class SDR;

class SDR
{
    float4 do_smth();
};

float4 SDR::do_smth()
{
    return float4(1.0, 0.0, 1.0, 1.0);
}

float4 PSMain(PSInput input) : SV_TARGET
{
    const SDR sdr;
	return sdr.do_smth();//input.color;
}

Is this by design? With a larger shader code base I find it very important to have a good overview of struct interfaces and data members and the implementation details separate.

I'm trying to debug the execution of one of my fragment shaders using RenderDoc, but I can't seem to deduce the required incantation to make slangc produce debug output. I have added the -g3, -O0, and "-Xglslang gVS" args to no avail.

Does slang not support source-level debugging or am I just missing something?

Thank you.