Making it easier to work with shaders https://git.yummers.dev/slang.git/atom?h=master 2025-10-13T14:14:45+00:00 2025-10-13T14:14:45+00:00 Ellie Hermaszewska ellieh@nvidia.com 2025-10-13T14:14:45+00:00 urn:sha1:96df31a9fa53e3d897a2b7c4eef021f37f421c91 Closes https://github.com/shader-slang/slang/issues/8154 However there is further design work to do on implementing the "NonAddressableType" suggestion 2025-10-11T00:31:01+00:00 Yong He yonghe@outlook.com 2025-10-11T00:31:01+00:00 urn:sha1:fb34bafd37e3509d51686ee2a5392d2d8e29d7c5 2025-10-03T04:48:11+00:00 Theresa Foley 10618364+tangent-vector@users.noreply.github.com 2025-10-03T04:48:11+00:00 urn:sha1:cc8f6a241edb47c43c5698ee33abed4fe57d4566 Note that while this change touched a large numer of files, there are no changes to functionality being made here. The only things being done are renaming various symbols and, in a few cases, updating or adding comments for consistency with the new names. The core of the naming changes are: * Most things named to refer to `OutType` (e.g., `IROutType`, `IRBuilder::getOutType()`, etc.) have been consistently renamed to refer to `OutParamType`, to emphasize that the relevant AST/IR node types are only intended for use to represent `out` parameters. * The same change as described above for `OutType` is also made for `RefType`, which becomes `RefParamType` in most cases. One mess that this exposes is the way that the `ExplicitRef<T>` type in the core module currently lowers to `IRRefParamType`. This change sticks to the rule of not making functional changes, so that mess is left as-is for now. * Names referring to `InOutType` have been changed to instead refer to `BorrowInOutType`. The intention with this naming change is to emphasize that the Slang rules for `inout` are semantically those of a borrow (or at least our interpretation of what a borrow means). * Names referring to `ConstRefType` have been changed to instead refer to `BorrowInType`. This change starts work on clarifying that the existing `__constref` modifier was never intended to be a read-only analogue of `__ref`, and instead is the input-only analogue of `inout`. * The `ParameterDirection` enum type has been changed to `ParamPassingMode`, to reflect the fact that the concept of "direction" fails to capture what is actually being encoded, particularly once we have modes beyond simple `in`/`out`/`inout`. While this change does not alter behavior in any case (the user-exposed Slang language is unchanged), it is intended to set up subsequence changes that will work to make the handling of these types in the compiler more nuanced and correct. Breaking this part of the change out separately is primarily motivated by a desire to minimize the effort for reviewers. --------- Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com> 2025-09-30T06:22:50+00:00 Ronan ro.cailleau@gmail.com 2025-09-30T06:22:50+00:00 urn:sha1:ee5adb87050ae7c0b96056a67dddc5d48174e695 Fixes #8439 When checked, generic type equality constraints types are now in a canonical order, allowing for a commutative type equality operator. --------- Co-authored-by: Mukund Keshava <mkeshava@nvidia.com> 2025-09-29T05:27:21+00:00 Copilot 198982749+Copilot@users.noreply.github.com 2025-09-29T05:27:21+00:00 urn:sha1:d3093deb49d1088ede6c3dcd418575bfa4bcd732 The Slang compiler was segfaulting when trying to compile shaders that return resource types (like `Texture2D`, `RWTexture2D`, `SamplerState`, etc.) from entry point functions. This occurred because there was missing validation that should reject such invalid return types before they reach IR generation. For example, this code would cause a segfault: ```slang StructuredBuffer<Texture2D<int>> skyLight; [shader("compute")] Texture2D<int> computeMain(uint3 threadID : SV_DispatchThreadID) { return skyLight[threadID.x]; } ``` ## Root Cause The issue was in the entry point validation logic in `validateEntryPoint()`. While there was a TODO comment indicating that return type validation should be performed, it was never implemented. The compiler would accept the invalid shader code and attempt to process it during IR lowering, where resource types as return values are not properly handled, leading to a segmentation fault. ## Solution 1. **Added robust validation**: Modified `validateEntryPoint()` in `slang-check-shader.cpp` to use the existing `SemanticsVisitor::getTypeTags()` functionality to check for invalid return types by detecting `TypeTag::Opaque` and `TypeTag::Unsized` bits. This leverages the existing type analysis infrastructure that comprehensively handles: - Direct resource types (Texture2D, RWTexture2D, SamplerState, etc.) - Structs containing resource-typed fields (through type tag propagation) - Nested structures and complex type hierarchies - Arrays and other composite types 2. **Added diagnostic message**: Uses existing diagnostic `entryPointCannotReturnResourceType` (error 38010) that provides a clear error message explaining why resource types cannot be returned from shader entry points 3. **Updated existing tests**: Modified existing tests to match the updated validation behavior ## Result Instead of a segfault, users now get a clear, actionable error message: ``` error 38010: entry point 'computeMain' cannot return type 'Texture2D<int>' that contains resource types ``` The fix properly handles all resource types including `Texture2D`, `RWTexture2D`, `SamplerState`, and others, while preserving the ability to compile valid shaders that return simple data types. Fixes #6438. <!-- START COPILOT CODING AGENT TIPS --> --- 💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: expipiplus1 <857308+expipiplus1@users.noreply.github.com> Co-authored-by: Ellie Hermaszewska <ellieh@nvidia.com> Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com> 2025-09-26T17:01:38+00:00 James Helferty (NVIDIA) jhelferty@nvidia.com 2025-09-26T17:01:38+00:00 urn:sha1:e9f74ebfa83cd6aca39d7e3da2801cd47935bd1a Generate a diagnostic warning whenever unsupported modifiers (keywords, attributes) are found on entry point parameters. These have been silently ignored up until now, with the parser accepting them but Slang not actually doing anything with them. Fixes #7151 --------- Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com> 2025-09-17T17:51:36+00:00 James Helferty (NVIDIA) jhelferty@nvidia.com 2025-09-17T17:51:36+00:00 urn:sha1:8d67365b36ea43d339911eba5ee1693d75ae58e2 When slang detects assignment to a mesh output reference on metal, generate a diagnostic message. (Metal mesh shader outputs must be assigned via 'set' instead of 'ref'.) Fixes #7498 2025-09-16T19:51:43+00:00 Gangzheng Tong tonggangzheng@gmail.com 2025-09-16T19:51:43+00:00 urn:sha1:afb8146e10626887e3eb9f479480d4f8a1ad6128 ## Summary This PR enhances constexpr validation by adding proper error checking when function arguments cannot satisfy constexpr parameter requirements, addressing issue #6370. ## Problem Previously, when a function declared constexpr parameters, the compiler would attempt to propagate constexpr-ness to the call site arguments, but there was insufficient validation and error reporting when this propagation failed. This could lead silent failures where constexpr requirements weren't properly enforced ## Solution This PR adds checks that: 1. **Validates constexpr arguments**: When a function parameter is marked as `constexpr`, the compiler now explicitly checks that the corresponding argument can be marked as `constexpr` 2. **Issues clear compilation errors**: added `Diagnostics::argIsNotConstexpr`) 3. **Handles both call scenarios**: The validation works for both: - Direct function calls with IR-level function definitions - Calls to function from external modules Fixes #6370 --------- Co-authored-by: slangbot <ellieh+slangbot@nvidia.com> Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com> 2025-09-06T05:37:34+00:00 Yong He yonghe@outlook.com 2025-09-06T05:37:34+00:00 urn:sha1:bc6b82666fa4deda932c36cea93ee2059e0992b2 This change relaxes a previous restriction on link-time types and constants, so that we now allow them to be used to define shader parameters. Doing so will result in a parameter layout that is incomplete prior to linking. The PR added a test to call the reflection API on a fully linked program and ensure that we can report correct binding info. 2025-09-03T20:05:26+00:00 Ellie Hermaszewska ellieh@nvidia.com 2025-09-03T20:05:26+00:00 urn:sha1:a766d27447aa0fcf69334c0467d9b1124892e180 closes https://github.com/shader-slang/slang/issues/3313