Making it easier to work with shaders https://git.yummers.dev/slang.git/atom?h=master 2025-10-03T19:52:26+00:00 2025-10-03T19:52:26+00:00 Yong He yonghe@outlook.com 2025-10-03T19:52:26+00:00 urn:sha1:6a2cf239a89340ed2985d04609499e8c4a2d8f89 Closes #7606. When Slang compile for a bindful target, we will run the resource type legalization pass to hoist resource typed struct fields outside of the struct type and define them as global parameters and passing them around via dedicated function parameters. When we compile for a bindless target, we don't run this pass. However, Metal is a hybrid bindful and bindless target. We need to run type legalization for the constant buffer, but skip type legalization for parameter block. The previous attempt to support this behavior is to hack the type legalization pass to return `LegalVal::simple` when it sees a `ParameterBlock<T>`. However, whenever the code is accessing `parameterBlock.someNestedField`, the type of the nested field may get a `LegalType::tuple`, and now we will run into inconsistent scenarios where we have a `LegalVal::simple` on the operand val, and but the legalization logic is expecting that val to be a `LegalType::tuple`. This breaks a lot of assumptions and invariants in the type legalization pass, resulting unstable/fragile behavior. To systematically solve this problem, this change generalizes the existing legalize buffer element type pass to translate `ParameterBlock<Texture2D>` (and similar cases) to `ParameterBlock<Texture2D.Handle>`. So that such parameter block will always be legalized to `LegalType:::simple` during type legalization, and we will never run into any inconsistent cases. This allowed us to get rid of the hacky logic in the type legalization pass to try to workaround the inconsistencies. 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-08-21T05:47:18+00:00 Julius Ikkala julius.ikkala@gmail.com 2025-08-21T05:47:18+00:00 urn:sha1:35f8e092f2aa3ed5e3cf03387e712f798ff4850e Closes #8112. ~~The issue asks for a "C layout", but in this PR I use the term "CPU layout" because this naming was pre-existing in the codebase as `kCPULayoutRulesImpl_`. The primary purpose of this layout is to match CPU-side struct definitions with the shader side. I'm open to better naming suggestions, though.~~ Edit: switched back to using `CDataLayout` & `-fvk-use-c-layout`, as the CPU target depends on the object layout rules of existing CPU layout rules, but they're incompatible with actual shaders. So a new `kCLayoutRulesImpl_` was needed anyway. --------- Co-authored-by: Ellie Hermaszewska <ellieh@nvidia.com> 2025-06-26T16:49:11+00:00 Julius Ikkala julius.ikkala@gmail.com 2025-06-26T16:49:11+00:00 urn:sha1:a58675b161d9fea8a73a6ded15e5a79b1fc020ef * Fix tuple AST & IR layout size queries * Don't peephole sizeof if size is still indeterminate 2025-06-10T15:02:38+00:00 James Helferty (NVIDIA) jhelferty@nvidia.com 2025-06-10T15:02:38+00:00 urn:sha1:e37202002276b679c5241b2678af612552b06d2c * Better handling for 16-byte boundary of d3d cbuffer Fixes #6921 D3D cbuffers have slightly different packing rules that allow packing vectors into a 16-byte slot at element alignments, except when a field would cross a 16-byte boundary. In that case, we need to realign the field to the next 16-byte boundary. In particular, this impacts vec3s, which are not a power of two in size and thus require slightly different alignment logic, compared to std430 and std140. (Example: a float and float3 should fit together in that order in a single slot.) Adds test cases. Adds documentation page for GLSL target 2025-05-03T20:27:03+00:00 Julius Ikkala julius.ikkala@gmail.com 2025-05-03T20:27:03+00:00 urn:sha1:6f6103c4dbc77d5bceae7c8e766ec3cabc293364 * Add IREnumType to distinguish enums from ints and each other * Add issue example as test * format code * Add expected test output * Fix peephole optimization hanging No idea why this PR triggered this, but there seems to have been a clear bug here anyway, so may just as well fix it now. * Move enum lowering later * Add linkage decoration to enum type * Use filecheck-buffer instead of expected.txt * Fix comment * Make enum casts actually use IR enum casts They were all BuiltinCasts by accident * Lower enum type before VM * Deal with rate-qualified types in enum cast * Allow any value marshalling for enum types * Handle new enum instructions in a couple more switches * Fix formatting --------- Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com> 2025-04-21T18:46:23+00:00 Darren Wihandi 65404740+fairywreath@users.noreply.github.com 2025-04-21T18:46:23+00:00 urn:sha1:62baf92a524a5b57eb465100a5e47c489c049f15 * Add struct member offset qualifier for SPIRV * Implement for GLSL target and add tests * clean up * fix formatting * fix typo * renamed GLSLStructOffset to VkStructOffset and added emit-spirv-via-glsl test case 2025-03-19T18:44:04+00:00 Yong He yonghe@outlook.com 2025-03-19T18:44:04+00:00 urn:sha1:4eb7a27ac4532a49b9d383d2b0d80bc0ec317b4c * Fix reinterpret and bitcast. * Fix warning. * Fix. * Fix. --------- Co-authored-by: Ellie Hermaszewska <ellieh@nvidia.com> 2025-03-06T22:26:34+00:00 Yong He yonghe@outlook.com 2025-03-06T22:26:34+00:00 urn:sha1:4485cf3eaf142cfd5f8470e86739acc67d4e12ea * Update SPIRV-Tools and fix new validation errors. * Implement pointers for glsl target. * Reworked packStorage/unpackStorage code gen to operate on pointers rather than values. 2025-03-01T06:46:56+00:00 Yong He yonghe@outlook.com 2025-03-01T06:46:56+00:00 urn:sha1:dd9d24d29c4a9e05a4510eb9959fafa0ed36618b * Allow partial specialization of existential arguments. * Fix. * Add test case for improved diagnostics. * Fix compile error. * Fix tests. * Fix. * Fix test. * Fix compile issue. * Fix typo. * Address comment.