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

HLSL sets __HLSL_VERSION to invalid version #6462

Closed
llvm-beanz opened this issue Feb 26, 2025 · 4 comments · Fixed by #6502
Closed

HLSL sets __HLSL_VERSION to invalid version #6462

llvm-beanz opened this issue Feb 26, 2025 · 4 comments · Fixed by #6502
Assignees
Labels
goal:quality & productivity Quality issues and issues that impact our productivity coding day to day inside slang

Comments

@llvm-beanz
Copy link

HLSL language versions are 2016, 2017, 2018, and 2021. Slang currently sets __HLSL_VERSION to 2020, which isn't a real HLSL language version:

combinedPreprocessorDefinitions.addIfNotExists("__HLSL_VERSION", "2020");

@bmillsNV bmillsNV added this to the Q1 2025 (Winter) milestone Feb 27, 2025
@bmillsNV bmillsNV added the goal:quality & productivity Quality issues and issues that impact our productivity coding day to day inside slang label Feb 27, 2025
@zlatinski
Copy link
Contributor

I think we should set the compiler to version 2021.
The compiler is already supporting the new HLSL 2021 features, such as:

  • Slang is already enforcing ternary operator behavior
  • Slang supports HLSL 2021 features like select()
// Test file with HLSL 2021 compliant code

// Simple entry point
float4 main() : SV_Target0
{
    // HLSL 2021 compliant example
    float4 a = float4(1.0, 2.0, 3.0, 4.0);
    float3 b = float3(5.0, 6.0, 7.0);
    bool condition = true;
    
    // This is valid in HLSL 2021 - explicit conversion
    float4 result = condition ? a : float4(b, 1.0);
    
    return result;
}
// Test file using HLSL 2021 select() function

// Simple entry point
float4 main() : SV_Target0
{
    float2 v = float2(0.5, -0.3);
    
    // Using select() function (HLSL 2021 style)
    float2 result = (1.0 - abs(v.yx)) * select(v.xy >= 0.0, 1.0, -1.0);
    
    return float4(result, 0.0, 1.0);
}
// Test file to check HLSL 2021 conditional operator behavior

// Simple entry point
float4 main() : SV_Target0
{
    // Pre-HLSL 2021 behavior example
    float4 a = float4(1.0, 2.0, 3.0, 4.0);
    float3 b = float3(5.0, 6.0, 7.0);
    bool condition = true;
    
    // This would work in pre-2021 HLSL but fail in HLSL 2021
    // (implicit conversion from float3 to float4)
    float4 result = condition ? a : b;
    
    return result;
}

@csyonghe
Copy link
Collaborator

csyonghe commented Mar 1, 2025

Defining it to 2021 is reasonable because slang’s semantics around these features is closer to HLSL 2021 than 2018.

The only downside is that if there are existing code using this to decide if they can use templates, they will fail when compiled by the slang compiler. But they will get more salient compiler errors there, and it is better than having things silently compiles to a different semantic without noticing.

@llvm-beanz
Copy link
Author

Setting to 2021 is very much the wrong move. That is how users determine the ability to overload operators and use templates. Both of which are incompatible with Slang.

select is available in DXC in all language modes.

@csyonghe
Copy link
Collaborator

csyonghe commented Mar 1, 2025

I think there isn't a perfect answer here. The ternary operator and logical short circuiting behavior is consistent with HLSL 2021, but given that this is already breaking our existing tests, setting to 2018 is likely the better answer.

What we need to do though is when the user is specifying -language HLSL, we need to ensure to turn off short circuiting. But this can come at a later patch. For now I agree that we should set it to 2018, if this is mostly used to determine support for operator overload and templates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
goal:quality & productivity Quality issues and issues that impact our productivity coding day to day inside slang
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants