slang.git/tests/pipeline/ray-tracing, branch master

Fix segmentation fault in ray tracing parameter consolidation. (#7997)

2025-07-31T22:49:39+00:00

* Initial plan * Fix segfault in ray tracing parameter consolidation Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com> * Fix. * Fix. * Keep entrypoint param layout consistent during `MoveEntryPointUniformParametersToGlobalScope`. * Fix. * fix. * Fix. * Fix pending layout handling. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com> Co-authored-by: Yong He

Feature/initialize list side branch (#6058)

2025-02-05T18:37:03+00:00

* SP004: implement initialize list translation to ctor - We synthesize a member-wise constructor for each struct follow the rules described in SP004. - Add logic to translate the initialize list to constructor invoke - Add cuda-host decoration for the synthesized constructor - Remove the default constructor when we have a valid member init constructor - Disable -zero-initialize option, will re-implement it in followup (#6109). - Fix the overload lookup issue When creating invoke expression for ctor, we need to call ResolveInvoke() to find us the best candidates, however the existing lookup logic could find us the base constructor for child struct, we should eliminate this case by providing the LookupOptions::IgnoreInheritance to lookup, this requires us to create a subcontext on SemanticsVisitor to indicate that we only want to use this option on looking the constructor. - Do not implicit initialize a struct that doesn't have explicit default constructor. Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>

Warn when inout parameter is never written (#4777)

2024-08-12T21:18:02+00:00

Addresses #4698 as one approach to diagnose the potential problem. Emit warnings when a user marks a parameter as `inout` but never writes to it in the function. A new intrinsic function `unmodified(out T)` has been added to explicitly indicate that an `inout` variable will not be modified in the function. This is only one way to address the specific validation error in #4698. In general it seems that DXC does some more extensive checks on actual struct fields (as opposed to observing arbitrary struct writes), so that will be the next step.

Capability System: Implicit capability upgrade warning/error (#4241)

2024-06-12T20:38:23+00:00

* capability upgrade warning/error adjusted implementation + tests to support a warning/error if capabilities are implicitly upgraded and test accordingly. * add glsl profile caps * add GLSL and HLSL capabilities to the associated capability * syntax error in capdef * only error if user explicitly enables capabilities 1. changed testing infrastructure to not set a `profile` explicitly, 2. Added tests to be sure this works as intended with user API and with slangc command line * Change capability atom definitions and how Slang manages them to fix errors 1. most `glsl_spirv` version atoms have been removed from `.capdef`, instead we will translate `spirv` version atoms into `glsl_spirv` since there is no point in writing the same code twice in `.capdef` files to define `spirv` versions. 2. add spirv version, and hlsl sm version (and equivlent) capability dependencies 3. removed some stage requirments which were set on objects, keep the wrapper capabilities. I am keeping the wrapper capabilities since I am unaware on if there are stage limitations (spec says code in practice does not work). * check internal version instead of version profile (_spirv_1_5 vs. spirv_1_5) * remove unused OpCapability. adjust SPIRV version'ing again for glsl_spirv * apply workaround for glslang bug with rayquery usage * ensure capabilities targetted by a profile and added together by a user are valid * remove additions to `spirv_1_*` wrapper * spirv_* -> glsl_spirv fix * fix bug where incompatable profiles would cause invalid target caps * try to avoid joining invalid capabilities * fix the warning/error & printing * run through tests to fix capability system and test mistakes many mistakes were mesh shaders doing `-profile glsl_450+spirv_1_4`. This is not allowed for a few reasons 1. the test tooling does not handle arguments the same as `slangc` 2. glsl_450 core profile does not support mesh shaders, nor does spirv_1_4. sm_6_5 does work in this senario * set some sm_4_1 intrinsics to sm_4_0 * replace `GLSL_` defs with `glsl_` * swap the unsupported render-test syntax for working syntax * set d3d11/d3d12 profile defaults this is required since sm version changes compiled code & behavior * adjusted nvapi capabilities with atomics + d3d11 set to use sm_5_0 as per default * cleanup * address review * incorrect styling * change `bitscanForward` to work as intended on 32 bit targets --------- Co-authored-by: Yong He

Proper lowering of functiosn that returns NonCopyable values. (#3179)

2023-09-03T19:56:31+00:00

* Proper lowering of functiosn that returns NonCopyable values. * Fix tests. * Fix clang errors. * Fix. * Fix clang error. --------- Co-authored-by: Yong He

Compile append and consume structured buffers to glsl. (#3142)

2023-08-22T00:07:34+00:00

* Compile append and consume structured buffers to glsl. * Fix. * Update CI config. --------- Co-authored-by: Yong He

Add warning on mutation of function parameter (#3067)

2023-08-08T05:23:31+00:00

By default, function parameters in HLSL are mutable, but any changes to a parameter do not affect the values of the arguments after a call: void f(int a) { a++; // allowed, but kind of useless } ... int b = 0; f(b); // b is still zero Because the above behavior is a part of HLSL, we cannot easily diagnose such cases as errors without breaking backward compatibility with existing code. This change makes it an error to invoke a `[mutating]` method on a function parameter, which cannot affect backward compatibility since the notion of `[mutating]` methods is not present in existing HLSL code: struct Counter { int _state; [mutating] void increment() { _state++; } } void f(Counter a) { a.increment(); // ERROR } ... Counter b = { 0 }; f(b); // b is still zero The compiler will also diagnose calls to `[mutating]` methods on a field or array element extracted out of a function parameter. This change does not affect code that directly mutates a function parameter via assignment, or via passing the parameter onward as an argument to an `out` or `inout` call (or, equivalently, as the left-hand operand to a compound assignment operator). This is a breaking change to existing Slang code, since it could diagnose an error on code that used to be allowed. Indeed, two tests in the Slang test suite had to be updated to avoid such errors. It would be possible to turn this diagnostic into a warning, and simply encourage users to enable it as an error. On balance, though, it seems best to not allow this idiom since it has such a high probability to be an error. Note: the specific case that motivated this change is use of `RayQuery` values as function parameters. The root of the problem there is that dxc treats `RayQuery` values as copyable handles to mutable state, while Slang prefers to capture the mutation that occurs through marking the appropriate methods as `[mutating]`. The Slang approach makes portable codegen for D3D/Vulkan simpler, but requires that we *also* treat a type like `RayQuery` as non-copyable. This change does not address the problem that the Slang compiler does not enforce the requirement that values of non-copyable types do not get copied. Instead, the diagnostic here just happens to issue a diagnostic in one important case where a copy would typically occur. Co-authored-by: Yong He

Fixes for Shader Execution Reordering on VK (#2929)

2023-06-13T21:40:02+00:00

* Fixes for Shader Execution Reordering on VK There are some mismatches between the way that hit objects are handled between the current NVAPI/HLSL and proposed GLSL extensions for shader execution reordering. These mismatches create complications for generating valid GLSL/SPIR-V code from input Slang. Many of the problems that apply to `HitObject` also apply to the existing `RayQuery<>` type used for "inline" ray tracing. In the case of `RayQuery<>` we have that for *both* HLSL and GLSL/SPIR-V: * A `RayQuery` (or `rayQueryEXT`) is an opaque handle to underlying mutable storage * The storage that backs a `RayQuery` is allocated as part of the "defualt constructor" for a local variable declared with type `RayQuery`. * The `RayQuery` API provides numerous operations that mutate the storage referred to by the opaque handle. The key difference between HLSL and GLSL/SPIR-V for the case of a `RayQuery` amounts to: * In HLSL, local variables of type `RayQuery` can be assigned to, and assignment has by-reference semantics. It is possible to create multiple aliased handles to the same underlying storage. * In GLSL/SPIR-V, local variables of type `rayQueryEXT` cannot be assigned to, returned from functions, etc. It is impossible to create multiple aliased handles to the same underlying storage. The case for `HitObject`s is signicantly *more* messy, because: * In NVAPI/HLSL a `HitObject` is effectively a "value type" in that it only exposes constructors, and there is no way to mutate the state of a `HitObject` other than by assignment to a variable of that type. It makes no semantic difference whether a `HitObject` directly stores the value(s), or if it is a handle, since there is no way to introduce aliasing of mutable state. Assignment of `HitObject`s semantically creates a copy. * In GLSL/SPIR-V, a `hitObjectNV` is, like a `rayQueryEXT`, a handle to underlying mutable state. These handles cannot be assigned, returned from functions, etc. There is no way to make a copy of a hit object. This change includes several changes to how *both* `RayQuery<>` and `HitObject` are implemented, with the intention of getting more cases to work correctly when compiling for GLSL/SPIR-V, and to set up a more clear mental model for the semantics we want to give to these types in Slang, and how those semantics can/should map to our targets. An overview of important changes: * Marked a few operations on `RayQuery` as `[mutating]` that realistically should have already been that way. * Marked the `HitObject` type as being non-copyable (an attribute we do not currently enforce), and marked the various GLSL operations that construct a hit object as having an `out` parameter of the `HitObject` type (even if they are nominally specified in GLSL as not writing to the correspondign parameter). * Added a distinct IR opcode (`allocateOpaqueHandle`) to represent the implicit allocation that happens when declaring a variable of type `HitObject` or `RayQuery`, and made the "implicit constructor" for those types map to the new op. This operation took a lot of tweaking to get emitting in a reasonable way, and I'm still not 100% sure that all of the emission-related logic for it is strictly required (or correct). * Added new IR instructions for `HitObject` and `RayQuery` types, and made the stdlib types map to those IR instructions. * Treat `HitObject` and `RayQuery` as resource types for the purpose of our existing pass that specializes calls to functions that have outputs of resource type * Added a new test case that includes a function that returns a `HitObject` as its result. * Many test cases saw slight changes in their output (especially around the relative ordering of declarations of `HitObject`s and `RayQuery`s with other instructions) * Remove debugging logic

Preserve type cast during AST constant folding. (#2912)

2023-05-31T21:28:45+00:00

* Preserve type cast during AST constant folding. Fixes #2891. * Fix. * Fix truncating. * fix test. --------- Co-authored-by: Yong He

Fix function side-effectness prop logic. (#2875)

2023-05-09T16:44:33+00:00