summaryrefslogtreecommitdiffstats
path: root/tests/hlsl
Commit message (Collapse)AuthorAge
* Fix#8086: Batch-10: Enable cuda tests (#8270)Harsh Aggarwal (NVIDIA)2025-09-03
|
* render-test: Change D3D12 default to sm_6_5 (#8320)James Helferty (NVIDIA)2025-09-02
| | | | | | | | | Changes default for render-test to sm_6_5. Since sm_6_5 is the new default, remove the -use-dxil option, add -use-dxcb option Remove -use-dxil option from all test cases. Add -use-dxcb to two tests that needed it. Fixes #7611
* Enable tests for CUDA (#7593)Mukund Keshava2025-07-03
| | | | | | | | Enable intrinsic tests for cuda. Most of these tests were either disabled or just not enabled for cuda. Fixes #7592 Co-authored-by: Ellie Hermaszewska <ellieh@nvidia.com>
* Fix argument to float3 cbuffer tests (#7391)James Helferty (NVIDIA)2025-06-12
| | | | | | | | Results of these tests had been marked ignored, because they failed on VK with the GLSL backend. This change removes them from the expected-failure.txt file and adds the correct command line option to avoid using the GLSL target. Addresses concern raised on #7282
* Allow checking capabilities in specific stages (#7375)jarcherNV2025-06-10
| | | | | | | This allows checking capabilities in any stage, needed specifically for the hlsl_2018 capability which is defined for sm_5_1 and above. Stage specific capabilities such as cs_5_1 would not find this in any stage other than compute, so we need to restrict the check to only desired stages.
* Fix IR layout of 3-element vectors in cbuffers for -fvk-use-dx-layout (#7282)James Helferty (NVIDIA)2025-06-10
| | | | | | | | | | | | | | | | | | | * 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
* Support Vulkan memory model (#7057)Jay Kwak2025-05-16
| | | | | | | | | | | | | | | The user can explicitly use Vulkan memory model, or it will be automatically used when cooperative-matrix is used. When vulkan memory model is used, two keywords, "Coherent" and "Volatile", are not allowed. There are many differences regarding atomic and texture but this PR has changes limited to support `globallycoherent` keyword. When variables with `globallycoherent` is used with `OpLoad`, it will use additional options, `MakePointerAvailable|NonPrivatePointer`, that will provide the same effect. For `OpStore`, it will use `MakePointerVisible|NonPrivatePointer`.
* Add checking for hlsl register semantic. (#7118)Yong He2025-05-15
| | | | | | | | | | | * Add checking for hlsl register semantic. * Fix. * Fix test. * Fix switch error. * Fix tests.
* Support for Payload Access Qualifiers (#3448) (#6595)Harsh Aggarwal (NVIDIA)2025-04-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add support for Ray Payload Access Qualifiers (PAQs) (#3448) - Added [raypayload] attribute for struct declarations - Implemented field validation requiring read/write access qualifiers - Added diagnostic error for missing qualifiers - Enabled PAQs in DXC compiler and HLSL emission - Added new test demonstrating PAQ syntax - Implemented proper handling of ray payload attributes in IR generation * format code * Cleanup: Remove unused vars * Add check to enablePAQ only for profile >= lib_6_7 * Review Fix - Add PAQ support for DX Raytracing add enablePAQ flag to DownstreamCompileOpitons, improve PAQ handling update raypayload-attribute-paq.slang to ensure hlsl and dxil is validated * Add diagnostic test for missing paq for lib_6_7 Compile using `-disable-payload-qualifiers` aka lib_6_6 profile raypayload-attribute-no-struct.slang and raypayload-attribute.slang --------- Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com> Co-authored-by: Ellie Hermaszewska <ellieh@nvidia.com>
* Emit errors for missing returns on unsupported targets (#6633)Darren Wihandi2025-03-21
| | | | | | | | | | | | | | | | | | | * initial wip * more WIP * preserve old lower behavior * remove unnecessary includes * add test * add no target case in test * fix broken test --------- Co-authored-by: Ellie Hermaszewska <ellieh@nvidia.com>
* HLSL: Add 'f' suffix to float literals in code generation (#6381)Mukund Keshava2025-02-20
| | | | | | | | | | | | | | | | | | | | | | | | * HLSL: Add 'f' suffix to float literals in code generation Fixes #6078 1) Previously, Slang would emit HLSL float literals without a suffix (e.g.,"1.5"), which caused DXC to interpret them as 64-bit doubles by default unless the -HV 202x flag was used. This could cause validation errors when these literals were used with intrinsics that only accept 32-bit floats (like ddx, ddy). This change modifies the HLSL emitter to explicitly add 'f' suffix to 32-bit float literals, ensuring they are correctly typed regardless of DXC's version or flags. For example: - "1.5" becomes "1.5f" - "(0.0 / 0.0)" becomes "(0.0f / 0.0f)" for NaN - "float4(1.0, 2.0, 3.0, 4.0)" becomes "float4(1.0f, 2.0f, 3.0f, 4.0f)" 2) Added a test case to verify the behavior with various float literal scenarios including basic literals, intrinsic calls, and vector construction. 3) Remove some tests that were marked as known failures * Add dxil test as suggested by jkwak-work
* Enable Hull shader test for SPIRV (#6348)Jay Kwak2025-02-14
| | | | | * Enable Hull shader test for SPIRV
* Add raypayload decoration to ray payload structs (#6164)Ellie Hermaszewska2025-02-11
| | | | | | | | | * Add raypayload decoration to ray payload structs Closes https://github.com/shader-slang/slang/issues/6104 * Disable PAQs when compiling with DXC See https://github.com/shader-slang/slang/issues/3448
* Refresh of disabled WGPU tests (#5614)Anders Leino2024-11-21
| | | | | | | | | Some tests are now passing and are enabled. Other tests are still failing, but are given comments categorizing the failures. Tests in the 'Not supported in WGSL' category are also removed from the expected failures list. (Though they are still kept disabled for WebGPU, of course.) This closes #5519.
* Enable a bunch of WGPU tests (#5513)Anders Leino2024-11-07
| | | This closes issue #5505.
* Update Slang-RHI again to get more WGPU fixes (#5475)Anders Leino2024-11-01
| | | | | | | | | | | | | This fixes a teardown crash, and a buffer usage mismatch issue during bind group creation. These Slang-RHI fixes allow several WGPU tests to be enabled: - tests/compute/column-major.slang - tests/compute/constant-buffer-memory-packing.slang - tests/compute/matrix-layout.hlsl - tests/compute/non-square-column-major.slang - tests/compute/row-major.slang - tests/hlsl/packoffset.slang This helps to address issue #5222.
* Enable WebGPU tests in CI (#5239)Anders Leino2024-10-15
|
* Initial `Atomic<T>` type implementation. (#5125)Yong He2024-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Initial Atomic<T> type implementation. * Update design doc. * Fix. * Add test. * Fixes and add tests. * Fix WGSL. * Fix glsl. * Fix metal. * experiemnt with github metal. * experiment github metal 2 * github metal experiment 3 * experiment with github metal 4. * experiment with metal 5. * experiment 7. * metal experiment 8. * Fix metal tests. --------- Co-authored-by: Yong He <yhe@nvidia.com>
* Fix Varying Variable Location Assignments With Hull Shaders (#4915)ArielG-NV2024-08-26
| | | | | | | | | | | | | | | | | | | | | * Fix Varying Variable Location Assignments With Hull Shaders Fixes: #4913 Fixes: #4540 Changes: 1. Added `kIROp_ControlBarrier` to HLSL/GLSL emitting. 2. Added a method to track 'used' and 'unused' varyings for when legalizing GLSL. This allows us to assign correct offsets to automatically added varyings * Added a `ZeroLSB` check to UIntSet for this purpose * add missing return * code comment adjustment * cleanup * comment and HLSL controlBarrier mistake * assume space for glsl/spriv varying is irrelevant
* Support HLSL `.sample` operators for MS textures (#4524)venkataram-nv2024-07-01
| | | | * Add `.sample` operator for MS texture types * Adding filecheck tests for `.sample`
* Implementing `tbuffer` layout(s) (#4436)ArielG-NV2024-06-24
| | | | | | | | | | | | | | | * Implementing `tbuffer` layouts. 1. Add to layout options 'TextureBuffer' layouts. 2. Add on to existing logic a way to allocate appropriate registers for TextureBufferType (this was made to work with parameter block logic). 3. Added asserts so objects missing a layout will gracefully crash This means `tbuffer` now works for hlsl,glsl,metal targets, spirv has yet to implement logic for `TextureBufferType`. * disable metal tests and fix emitting code a bit fixing the emitting code means metal compilation emits a useful error (help point users/developers to #4435) * fix warning
* Metal: misc fixes and enable more tests. (#4374)Yong He2024-06-13
| | | | | | | | | | | | | | | | | * Fix and enable tests for metal. * Fix. * Fix. * Fix tests. * Fix warnings. * Fix. --------- Co-authored-by: Yong He <yonghe@Yongs-Mac-mini.local>
* Implicit register binding for hlsl to non-hlsl targets (#4338)ArielG-NV2024-06-12
| | | | | | | | | | | | | | | | | | | | | * implicit register binding for hlsl to non-hlsl targets * fix regressions only warn once with `_maybeDiagnoseMissingVulkanLayoutModifier` remove unneeded else * address review and change bindings address review comments on testing to make the tests indiscriminate over order of code emitted. Change bindings to 1:1 map to vulkan bindings * don't set bindings 1:1 with vulkan if command line option was added --------- Co-authored-by: Yong He <yonghe@outlook.com>
* SPIRV `Block` decoration fixes. (#4303)Yong He2024-06-08
| | | | | | | | | | | | | | | * SPIRV `Block` decoration fixes. - SPIRV does not allow duplicate `Block` decorations. So we shouldn't be generating them. - Also fixes duplication of OpName. - SPIRV and HLSL do not allow ConstantBuffer with trailing unsized arrays. Added a check in the front-end against such code. * Convert failing cross-compile tests to filecheck. --------- Co-authored-by: Jay Kwak <82421531+jkwak-work@users.noreply.github.com>
* Support HLSL `.mips` syntax. (#4310)Yong He2024-06-07
|
* Metal compute tests (#4292)skallweitNV2024-06-07
|
* RasterizerOrder resource for spirv and metal. (#4175)Yong He2024-05-16
| | | | | | | | | | | | | * RasterizerOrder resource for spirv and metal. Also fixes the byte address buffer logic for metal. * Fix. * Delete commented lines. --------- Co-authored-by: Jay Kwak <82421531+jkwak-work@users.noreply.github.com>
* Support combined texture sampler when targeting HLSL. (#3963)Yong He2024-04-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Support combined texture sampler when targeting HLSL. * Fix glsl intrinsics. * Update source/slang/slang-ir-lower-combined-texture-sampler.cpp Co-authored-by: ArielG-NV <159081215+ArielG-NV@users.noreply.github.com> * Update source/slang/slang-ir-lower-combined-texture-sampler.cpp Co-authored-by: ArielG-NV <159081215+ArielG-NV@users.noreply.github.com> * Update source/slang/slang-ir-lower-combined-texture-sampler.cpp Co-authored-by: ArielG-NV <159081215+ArielG-NV@users.noreply.github.com> * Fix., * Enhance test. * Remove unused field. * Fix indentation --------- Co-authored-by: ArielG-NV <159081215+ArielG-NV@users.noreply.github.com>
* Fix typelayout for append/consume structured buffers. (#3924)Yong He2024-04-10
|
* Support SM6.6 keyword "WaveSize" (#3871)Jay Kwak2024-04-01
| | | | | | | | | Resolves an issue #3385 Shader Model 6.6 added a new keyowrd, "WaveSize". See the following link for more details: https://microsoft.github.io/DirectX-Specs/d3d/HLSL_SM_6_6_WaveSize.html Co-authored-by: Yong He <yonghe@outlook.com>
* Make `-no-mangle` option work, add `-no-hlsl-binding`. (#3817)Yong He2024-03-23
|
* Type layouts for structured buffers with counters (#3269)Ellie Hermaszewska2023-10-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * More tests for append structured buffer * Append and Consume structured buffer tests for DX12 * neaten * test wobble * Add counter layout information to append/consume structured buffers * add getRWStructuredBufferType * Correct definition of get size for append/consume structured buffers * tweak append structured buffer test * Allow initializing counter buffer in render test * vulkan test for consume structured buffer * Handle null counterVarLayout in getExplicitCounterBindingRangeOffset * remove dead code * Implement atomic counter increment/decrement for spirv * explicit spirv test * Add missing check on result * Hold on to counter resources --------- Co-authored-by: Yong He <yonghe@outlook.com>
* Make `-fvk-u-shift` work on AppendStructuredBuffer. (#3144)Yong He2023-08-22
| | | Co-authored-by: Yong He <yhe@nvidia.com>
* Compile append and consume structured buffers to glsl. (#3142)Yong He2023-08-21
| | | | | | | | | | | * Compile append and consume structured buffers to glsl. * Fix. * Update CI config. --------- Co-authored-by: Yong He <yhe@nvidia.com>
* Remove -use-glsl-matrix-layout-modifier from test (#3104)Ellie Hermaszewska2023-08-15
| | | Co-authored-by: Yong He <yonghe@outlook.com>
* Support per field matrix layout (#3101)Yong He2023-08-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | * Support per field matrix layout * Fix warnings. * Fix. * Fix tests. * Fix spiv gen. * Fix. * More test fixes. * Fix. * Run only GPU tests on self-hosted servers. * Remove -use-glsl-matrix-layout-modifier. * Fix. --------- Co-authored-by: Yong He <yhe@nvidia.com>
* Support `-fvk-use-gl-layout` for ByteAddressBuffer load/store. (#3068)Yong He2023-08-08
| | | | | | | | | | | | | * Support `-fvk-use-gl-layout` for ByteAddressBuffer load/store. * Fix. * Fix. * Add test for unaligned load. --------- Co-authored-by: Yong He <yhe@nvidia.com>
* Various dxc/fxc compatibility fixes. (#2863)Yong He2023-05-02
| | | | | | | | | | | | | * Various dxc/fxc compatibility fixes. * Cleanup. * Fix test cases. * Fix comments. --------- Co-authored-by: Yong He <yhe@nvidia.com>
* Warning on lossy implicit casts. (#2367)Yong He2022-08-17
| | | | | | | | | | | | | | | * Warning on bool to float conversion. * Fix test cases. * Improve. * LanguageServer: don't show constant value for non constant variables. * Fix tests. * Fix warnings in tests. Co-authored-by: Yong He <yhe@nvidia.com>
* Initial work around groupshared (#2224)jsmall-nvidia2022-05-06
| | | | | | | | | * #include an absolute path didn't work - because paths were taken to always be relative. * Allow rate modifier on parameter. * Add test. * Disable test for now as breaks on source comparison because around nvAPI.
* Feature/serialization debug info (#767)jsmall-nvidia2019-01-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Remove AppContext. Use StdChannels to hold writers, and TestToolUtil to hold test tool specific functionality. * StdChannels -> StdWriters * getStdOut -> getOut, getStdError -> getError * Renamed main.cpp files of tools to try and stop visual studio getting confused between files - such that clicking on an error takes editor to the right location. * Work in progress on being able to serialize debug information. * * Added MemoryStream * First pass converting to IRSerialData * Able to read and write IRSerialData with debug data * Start at reconstruting IR serialized data. * First pass of generation debug SourceLocs from debug data. Works for test set for line nos. * Bug fixes. Moved testing of serialization into IRSerialUtil * Work around problem with irModule = generateIRForTranslationUnit(translationUnit); two times in a row produces different output(!). Fix by just creating once. * Remove problem with use of ternary op in slang.cpp on gcc/clang. * Added -verify-debug-serial-ir option that makes IR modules go through full serialization with debug information and verification. * Add a test that does serial debug verification that is run by default on linux.
* Change how buffers are emitted (#741)Tim Foley2018-12-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Change how buffers are emitted This is a change with a lot of pieces, which can't always be separated out cleanly. I'm going to walk through them in what I hope is a logical order. The main goal of this change was to allow arrays of structured buffers to translate to Vulkan. Consider two declarations of structured buffers in HLSL/Slang: ```hlsl StructuredBuffer<X> single; StructuredBuffer<Y> multiple[10]; ``` The current translation logic was handling `single` by translating it into an *unnamed* GLSL `buffer` block like: ```glsl layout(std430) buffer _S1 { X single[]; }; ``` That syntax allows an expression like `single[i]` in Slang to be translated simply as `single[i]` in GLSL. But that naive translating doesn't work for `multiple`, since we need to declare a array of blocks in GLSL, which requires giving the whole thing a name: ```glsl layout(std430) buffer _S2 { Y _data[]; } multiple[10]; ``` Now a reference to `multiple[i][j]` in Slang needs to become `multiple[i]._data[j]` in GLSL. To avoid having way too many special cases around single structured buffers vs. arrays, it makes sense to allows emit things in the latter form, so that we instead lower `single` as: ```glsl layout(std430) buffer _S1 { X _data[]; } single; ``` So that now a reference to `single[i]` becomes `single._data[i]` in GLSL. Most of that can be handled in the standard library translation of the structured buffer indexing operations. The only wrinkle there is that there were some *old* special-case instructions in the IR intended to handle buffer load/store operations (these were added back when I was trying to keep the "VM" path working). These aren't really needed to have structured-buffer operations work; they can be handled as ordinary functions as far as the stdlib is concerned. I removed the old instructions. Along the way, it became clear that a few other cases follow the same pattern. Byte-addressed buffers are an obvious case. We were lowering HLSL/Slang: ```hlsl ByteAddressBuffer b; ... uint x = b.Load(0); ``` to GLSL like: ```glsl layout(std430) buffer _S1 { uint b[]; }; ... uint x = b[0]; ``` That logic would fail for arrays the same way that the structured buffer case was failing. The fix is the same: use named `buffer` blocks and then introduce an explicit `_data` field: ```glsl layout(std430) buffer _S1 { uint _data[]; } b; ... uint x = b._data[0]; ``` Just like with structured buffers, all of the VK translation for operations on byte-addressed buffers can be implemented directly in teh stdlib, so once the emit logic was changed it was just a matter of adding `._data` to a bunch of VK tranlsations. It turns out that arrays of constant buffers have more or less the same problem, and furthermore we have some problems with any code that directly uses the modern HLSL `ConstantBuffer<T>` type. Note: the emit logic around constant buffers sometimes refers to "parameter groups" because that is being used in the compiler as a catch-all term for constant buffers, texture buffers, and parameter blocks. The existing code was going out of its way to reproduce the way that constant buffer declarations are implicitly referenced in HLSL: ```hlsl cbuffer C { float f; } ... float tmp = f; // No reference to `C` here ``` This can be seen in the emit logic with the `isDerefBaseImplicit` function, which is used to take the internal IR representation for a reference to `f` (which is closer to the expression `(*C).f` or `C->f`) and leave off any reference to `C` so that we emit just `f`. That kind of logic just flat out doesn't work in some important cases. Arrays of constant buffers are a clear one: ```hlsl ConstantBuffer<X> cbArray[3]; ... X x = cbArray[0]; ``` There is no way to translate that to an ordinary `cbuffer` declaration at all. The same problem can be created without arrays, though: ```hlsl ConstantBuffer<X> singleCB; ... X x = singleCB; ``` The current strategy for translating constant buffers was translating `singleCB` into a `cbuffer` declaration that reproduced the fields of `X` as its members, which just wouldn't work: ```hlsl cbuffer singleCB { float f; // field of `X` } ... X x = singleCB; // ERROR: there is nothing named `singleCB` in this HLSL ``` The new strategy is more consistent. We still generate a `cbuffer` declaration for a single constant buffer, but we always give it a single field of the chosen element type: ```hlsl cbuffer singleCB { X singleCB; } ... X x = singleCB; // this works fine! ``` And in the array case we generate code that uses the explicit `ConstantBuffer<T>` type: ```hlsl ConstantBuffer<X> cbArray[3]; ... X x = cbArray[0]; ``` The GLSL output is more complicated because unlike with HLSL there is no implicit conversion from a uniform block to its element type (there is no notion of an element type). The array case thus needs a `_data` field similar to what we do for structured buffers: ```glsl layout(std140) uniform _S3 { X _data; } cbArray[3]; ... X x = cbArray[0]._data; ``` And then the non-array case needs to have a similar `_data` field for consistency: ```glsl layout(std140) uniform _S1 { X _data; } singleCB; ... X x = singleCB._data; ``` This is handled by inserting the necessary reference to `_data` whenever we dereference a constant buffer, either as part of a load instruction (loading from the whole CB as a pointer), or an `IRFieldAddress` instruction which forms a pointer into the CB (e.g., `&(singleCB->f)` becomes `singleCB._data.f`). The current emit logic handles `ParameterBlock<X>` differently from `ConstantBuffer<X>`, but really only to allow parameter blocks to be explicitly named in the output, while constant buffers were left implicit by default. Thus the only difference was a legacy one (from back when trying to exactly reproduce the HLSL text we got as input was considered an important goal), and the new approach to emitting constant buffers would get rid of it. I removed the separate logic for emitting `ParameterBlock<X>` and just let the handling for constant buffers deal with it. Note that any resource types inside of a `ParameterBlock<X>` would have been moved out as part of legalization, so that a parameter block is 100% equivalent to a constant buffer when it comes time to emit code. Unsurprisingly, changing the way we generate HLSL and GLSL output for all these buffer types meant that any tests that were directly comparing the output of `slangc` against `fxc`, `dxc`, or `glslang` broke. The basic approach to fixing the breakage in GLSL tests was to update the GLSL baseline to reflect the new output startegy. In some cases I used macros to name the various `_S<digits>` temporaries so that future renaming will hopefully be easier (it would be great if we auto-generated temporary names with a bit more context). There was one GLSL test (`tests/bugs/vk-structured-buffer-binding`) that was using raw GLSL expected output, and this was changed to use a GLSL baseline to generate SPIR-V for comparison. For HLSL tests we were sometimes running the same input file through `slangc` and `fxc`/`dxc`, and in these cases I macro-ized the various `cbuffer` declarations to generate different declarations depending on the compiler. I completely dropped the tests coming from the D3D SDK because they aren't providing much coverage, and updating them would change them so far from the original code that the purported benefit (using a body of existing shaders) would be lost. I also dropped the explicit matrix layout qualifiers in the `matrix-layout` test because the new output strategy breaks those for GLSL (you can't put matrix layout qualifiers on `struct` fields, and now the body of every constant buffer is inside a `struct`). This isn't as big of a loss as it seems, because our handling of those qualifiers wasn't really right to begin with. Slang users should only be setting the matrix layout mode globally (and we should probably switch to error out on the explicit qualifiers for now). The other thing that got dropped is tests involving `packoffset` modifiers. Slang already warns that it doesn't support these, and the way they were used in the test cases is actually misleading. For the binding/layout-related tests, the goal was to show that Slang reproduces the same layout as fxc, in which case explicitly enforcing a layout via `packoffset` seems like cheating (are we sure we enforced the layout fxc would have produced?). The real reason was that Slang used to emit explicit `packoffset` on *every* field of a `cbuffer` it would output, because of an `fxc` bug where you couldn't use `register` on textures/samplers declared inside a `cbuffer` unless *every* field in the `cbuffer` used a `register` or `packoffset` modifier. Slang hasn't required that behavior in a while because it now splits textures and samplers, and the one test case where we needed `packoffset` to work around the `fxc` bug in the baseline HLSL has been macro-ified even more to work around the bug. The amount of churn in the test cases is unfortunate, but it continues to point at the weakness of any testing strategy that checks for exact equivalent between Slang's output and that of other compilers. We need to keep working to replace these tests with better alternatives. In `check.cpp` there is logic to perform implicit dereferencing, so that if you write `obj.f` where `obj` is a `ConstantBuffer<X>` (or some other "pointer-like" type) and `f` is a field in `X`, then this effectively translates as `(*obj).f`. That is, we dereference the value of type `ConstantBuffer<X>` to get a value of type `X`, and then refer to the field of the `X` value. There was a problem where the logic to insert that kind of implicit dereference operation was using a reference (`auto& type = ...`) for the type of the expression being dereferenced, and then clobbering it. This would mean that an expression of type `ConstantBuffer<X>` would have its type overwritten to be just `X` and then codegen would break later on. I'm not sure how we haven't run into that before. The `array-of-buffers` test case was added to confirm that we now support arrays of constant, structured, and byte-address buffers for both DXIL and SPIR-V output. Okay, so that was a lot of stuff, but hopefully it is clear how this all works to make the output of the compiler more consistent and explicit, while also supporting the required new functionality. * fixup: review feedback
* Add support for globallycoherent modifier (#732)Tim Foley2018-11-29
| | | | | | | | | The `globallycoherent` modifier indicates that resource might be read or written by threads outside of the current thread group, so that any memory barriers that affect it should guarantee coherency at the global memory scope, and not just thread-group scope. The equivalent GLSL modifier appears to be `coherent`. This change adds the front-end modifier, transforms it into an IR-level decoration during lowering, and then checks for the modifier during code emit. Note: this logic may not behave correctly when `globallycoherent` is added to a field in a `struct`, since the modifier would then need to be propagated to any variables created during type legalization. Checking up on that is left to future work. Note: it isn't entirely clear if `globallycoherent` should be treated as a declaration modifier or a type modifier. The point is moot for now because Slang doesn't have any support for type modifiers, but when we get around to that we will need to make a decision.
* Fix declaration of RWTexture*.Load() operations (#722)Tim Foley2018-11-19
| | | | | | | | | | The `Texture2D.Load()` operation takes a `uint3` of coordinates, with the `.xy` part holding the texel coordinates and the `.z` part holding a mip level. In contrast, the `RWTexture2D.Load()` operation only takes a `uint2`. This isn't clearly specified on MSDN, so Slang failed to get the declaration right. This change fixes it so that we only add the extra coordinate for the mip level on non-multisample, read-only texture types (the previous code only checked for multisample-ness). I also changed the logic that outputs swizzles to extract the coordinates and mip level so that it only applies when there is a mip level being passed through (this code should never actually be applied, though, because we shouldn't be generating `texelFetch` for RW texures anyway...). One final change that sneask in here is making the `offset` parameter for one of the load-with-offset cases correctly use the base coordinate count for the texture type (e.g., 2D even for `Texture2DArray`). That is an unrelated fix, but I thought I'd sneak it in here rather than do a separate PR.
* Rework command-line options handling for entry points and targets (#697)Tim Foley2018-10-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Rework command-line options handling for entry points and targets Overview: * The biggest functionality change is that the implicit ordering constraints when multiple `-entry` options are reversed: any `-stage` option affects the `-entry` to its *left* instead of to its *right* as it used to. This is technically a breaking change, but I expect most users aren't using this feature. * The options parsing tries to handle profile versions and stages as distinct data (rather than using the combined `Profile` type all over), and treats a `-profile` option that specifies both a profile version and a stage (e.g., `-profile ps_5_0`) as if it were sugar for both a `-profile` and a `-stage` (e.g., `-profile sm_5_0 -stage fragment`). * We now technically handle multiple `-target` options in one invocation of `-slangc`, but do not advertise that fact in the documentation because it might be confusing for users. Similar to the relationship between `-stage` and `-entry`, any `-profile` option affects the most recent `-target` option unless there is only one `-target`. * The logic for associating `-o` options with corresponding entry points and targets has been beefed up. The rule is that a `-o` option for a compiled kernel binds to the entry point to its left, unless there is only one entry point (just like for `-stage`). The associated target for a `-o` option is found via a search, however, because otherwise it would be impossible to specify `-o` options for both SPIR-V and DXIL in one pass. * The handling of output paths for entry points in the internal compiler structures was changed, because previously it could only handle one output path per entry point (even when there are multiple targets). The new logic builds up a per-target mapping from an entry point to its desired output path (if any). Details: * Support for formatting profile versions, stages, and compile targets (formats) was added to diagnostic printing, so that we can make better error messages. This is fairly ad hoc, and it would be nice to have all of the string<->enum stuff be more data-driven throughout the codebase. * Test cases were added for (almost) all of the error conditions in the current options validation. The main one that is missing is around specifying an `-entry` option before any source file when compiling multiple files. This is because the test runner is putting the source file name first on the command line automatically, so we can't reproduce that case. * Several reflection-related tests now reflect entry points where they didn't before, because the logic for detecting when to infer a default `main` entry point have been made more loose * On the dxc path, beefed up the handling of mapping from Slang `Profile`s to the coresponding string to use when invoking dxc. * A bunch of tests cases were in violation of the newly imposed rules, so those needed to be cleaned up. * There were also a bunch of test cases that had accidentally gotten "disabled" at some point because there were comparing output from `slangc` both with and without a `-pass-through` option, but that meant that any errors in command-line parsing produced the *same* error output in both the Slang and pass-through cases. This change updates `slang-test` to always expect a successful run for these tests, and then manually updates or disables the various test cases that are affected. * When merging the updated test for matrix layout mode, I found that the new command-line logic was failing to propagate a matrix layout mode passed to `render-test` into the compiler. This was because the `-matrix-layout*` options were implemented as per-target, but the target was being set by API while the option came in via command line (passed through the API). It seems like we want matrix layout mode to be a global option anyway (rather than per-target), so I made that change here. * Add missing expected output files * A 64-bit fix * Remove commented-out code noted in review
* Remove need of IRHightLevelDecoration in emit (#660)jsmall-nvidia2018-10-04
| | | | | | | * * Remove the need for IRHighLevelDecoration in Emit * Use the IRLayoutDecoration for GeometryShaderPrimitiveTypeModifier * Fixing problems with comparison due to naming differences with slang/fxc.
* Pass through original names for most declarations (#547)Tim Foley2018-05-03
| | | | | | | | | | | | | | | | | | | The basic idea here is that when lowering to the IR, the front-end will attach a "name hint" to the IR instruction(s) that represent a given declaration, and then the passes that work on the IR will try to preserve and propagate those names, and then finally the emit logic will use them in place of mangled or unique names when available. This change does *not* try to deal with the issues that arise when we try to use those variable names in the output without any modification (e.g., handling cases where they might clash with keywords or builtins in the target language). Instead, it tries to establish baseline behavior for propagating through names, so that a later change can concentrate on the issue of using those names exactly when it is legal to do so. In order to avoid issues around the name "hints" causing problems we take two main steps: 1. We "scrub" each name to reduce it down to the allowed set of identifier characters in C-like languages, and then ensure that it doesn't do things that would be illegal in some downstream languages (e.g., consecutive underscores are not allowed in GLSL) or could clash with Slang's mangled names. This process isn't guaranteed to give distinct results for distinct inputs (it isn't a mangling scheme, after all). 2. We generate a unique ID for each occurence of a given name and always use that as a suffix. This means that even if a name happens to overlap with a keyword (if you somehow have a variable named `do`), we will still add a suffix that makes it not a problem (we'd output `do_0` which is fine). The logic for generating these names is mostly straightforward. For simple variables, we use their given name directly, while for other declarations we try to form a name that includes their parent declaration (e.g. `SomeType.someMethod`). Various IR passes need to propagate or preserve this information. The most interesting is type legalization, when we take a variable with an aggregate type and split some of the fields out into their own variables. In that case we generate "dotted" names like `someVar.someTexture` and rely on the emit logic to turn that into `someVar_someTexture`. During SSA generation, if we are promoting a variable to SSA temporaries, we will try to propagate the name of the variable over to the temporaries (unless they already have a name from some other place). The same applies to block parameters ("phi nodes"). Many of the test changes need their expected output to be updated for this change. Luckily in most cases the output has gotten easier to understand.
* Add support for explicit register space bindings (#542)Tim Foley2018-05-02
| | | | | | | | | | | | | | | | | | | | | | | This change adds support for specifying explicit register spaces, like: ```hlsl // Bind to texture register #2 in space #1 Texture2D t : register(t2, space1); ``` I added a test case to confirm that the register space is properly propagated through the Slang reflection API. This change also adds proper error messages for some error/unsupported cases that weren't being diagnosed: * Specifying a completely bogus register "class" (e.g., `register(bad99)`) * Failing to specify a register index (`register(u)`) * Specifying a component mask (`register(t0.x)`) * Using `packoffset` bindings I added test cases to cover all of these, as well as the new errors around support for register `space` bindings. In order to get the existing tests to pass, I had to remove explicit `packoffset` bindings from some DXSDK test shaders. None of these `packoffset` bindings were semantically significant (they matched what the compiler would do anyway, for both Slang and the standard HLSL compiler). Removing them is required for Slang now that we give an explicit error about our lack of `packoffset` support. In a future change we might add logic to either detect semantically insignificant `packoffset`s, or to just go ahead and support them properly (as a general feature on `struct` types).
* Introduce an IR-level type system (#481)Tim Foley2018-04-11
| | | | | | | | | | | | | | | | | * Introduce an IR-level type system Up to this point, the Slang IR has used the front-end type system to represent types in the IR. As a result (but ultimately more importantly) the IR representation of generics and specialization has used AST-level concepts embedded in the IR. For example, to express the specialization of `vector<T,N>` to a concrete type `float` for `T`, we needed an IR operation that could represent the specialization, with operands that somehow represented the type argument `float`. The whole thing was very complicated. The big idea of this change is to introduce a new representation in which types in the IR are just ordinary instructions, so that using them as operands makes sense. The hierarchy of IR types closely mirrors the AST-side hierarchy for now, and that will probably be something we should maintain going forward. In order to make these changes work, though, I also had to do major overhauls of things like the way substitutions are performed, how we check interface conformances, the way lookup through interface types is done, etc. etc. This is a big change, and unfortunately any attempt to summarize it in the commit message wouldn't do it justice. * Fix 64-bit build warning * Fix up some clang warnings/errors
* Change uses of "spire" to "slang" (#461)Tim Foley2018-03-29
| | | | | | | | | | | Fixes #350 When the Slang project forked off from the Spire research effort, we renamed things as we went, but many cases seem to have slipped through the cracks. The two biggest diffs here are: - The `hello` example program was incorrectly talking about what was in the shader file (Slang no longer supports the "module" or "pipeline" constructs from Spire), and so it wasn't just a simple rename. - The files under `tests/bindings` were mistakenly using `__SPIRE__` as a preprocessor guard, which means that they weren't actually testing what they meant to. Luckily, it looks like the relevant functionality didn't regress while these tests were unintentionally deactivated.