Making it easier to work with shaders https://git.yummers.dev/slang.git/atom?h=master 2024-11-21T07:37:28+00:00 2024-11-21T07:37:28+00:00 Anders Leino aleino@nvidia.com 2024-11-21T07:37:28+00:00 urn:sha1:93f5d13fc90c518ef2829dc16c28f0403e230337 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. 2024-10-07T17:16:19+00:00 Anders Leino aleino@nvidia.com 2024-10-07T17:16:19+00:00 urn:sha1:509409ef11e3b1abd1d7e1bfb540bc172aa1a817 * Use the assembly description as target when disassembling I believe this is a bugfix. It seems to have worked before because up until the WGSL case, the disassembler has been the same executable as the one producing the binary to be disassembled. * Add Tint as a downstream compiler This closes issue #5104. * Add downstream compiler for Tint. * Tint is wrapped in a shared library, 'slang-tint' available from [1]. * The header file for slang-tint.dll is added in external/slang-tint-headers. * Add some boilerplate for WGSL targets. * Add an entry point test for WGSL. [1] https://github.com/shader-slang/dawn/releases/tag/slang-tint-0 * Add WGSL_SPIRV as supported target for Glslang * Add WebGPU support to slang-test This helps to address issue #5051. * Disable lots of crashing compute tests for 'wgpu' This closes issue #5051. --------- Co-authored-by: Yong He <yonghe@outlook.com> 2024-06-26T05:07:41+00:00 Jay Kwak 82421531+jkwak-work@users.noreply.github.com 2024-06-26T05:07:41+00:00 urn:sha1:969dd4cc7246bfe89103efcb00f399606e804e98 * Support atomic intrinsics for Metal This commit adds a support for the atomic intrinsics in Metal. The atomic member functions for buffers is not implemented yet. Metal requires the first argument for the atomic functions to be an atomic data type. This implementation rely on the fact that we can do a C-style type casting from a regular data type to an atomic data type. 2024-06-07T07:28:16+00:00 skallweitNV 64953474+skallweitNV@users.noreply.github.com 2024-06-07T07:28:16+00:00 urn:sha1:004fe27a52b7952111ad7e749397aeff499de7ed 2021-01-15T20:10:06+00:00 Tim Foley tfoleyNV@users.noreply.github.com 2021-01-15T20:10:06+00:00 urn:sha1:2a5d5b32348c33aac7ca62aa9a4c2bb7cff8e08a This change converts a large number of our existing tests to use the `ShaderObject` support that was added to the `gfx` layer. In many cases, tests were just updated to pass `-shaderobj` and the result Just Worked. In other cases, a `name` attribute had to be added to one or more `TEST_INPUT` lines. For tests that did not work with shader objects "out of the box," I spent a little bit of time trying to get them work, but fell back to letting those tests run in the older mode. Future changes to the infrastructure will be needed to get those additional tests working in the new path. Along with the changes to test files, the following implementation changes were made to get additional tests working: * Because the shader object mode uses explicit register bindings (from reflection), the hacky logic that was offseting `u` registers for D3D12 based on the number of render targets gets disabled (by another hack). * The "flat" reflection information coming from Slang was not correctly reporting "binding ranges" for things that consumed only uniform data (which would be everything on CUDA/CPU), so it was refactored to properly include binding ranges for anything where the type of the field/variable implied a binding range should be created (even if the `LayoutResourceKind` was `::Uniform`). * A few fixes were made to the CUDA implementation of `Renderer`, in order to get additional tests up and running. Most of these changes had to do with texture bindings, which hadn't really been tested previously. In addition, a few changes were made that were attempts at getting more tests working, but didn't actually help. These could be dropped if requested: * As a quality-of-life feature (not being used) the `object` style of `TEST_INPUT` line is upgraded to support inferring the type to use from the type of the input being set. * Any `object` shader input lines get ignored in non-shader-object mode. 2020-04-23T18:40:01+00:00 jsmall-nvidia jsmall@nvidia.com 2020-04-23T18:40:01+00:00 urn:sha1:6f5c250b19b03a8eb4b6a9254613ce8539769a23 * Use the original value in the test. Run test on VK. * Added RWBuffer and Buffer types to C++ prelude. * Add vk to atomics.slang tests * Update target-compatibility around atomics. When tests disabled in atomics-buffer.slang explained why. * tabs -> spaces. * Small docs improvement. 2020-02-12T14:15:47+00:00 jsmall-nvidia jsmall@nvidia.com 2020-02-12T14:15:47+00:00 urn:sha1:fe9d27af9de047ea75db1334c961bb025fb732f6 * * Improved fastRemoveAt * Fixed off by one bug * Fixed const safeness with List<> * Made List begin and end const safe. * Revert to previous RefPtr usage. * Fix bug with casting. * Tabs -> spaces. Small fixes/improvements to List. * Improve comment on List. * Group shared/atomic test works on CUDA. * * Enabled CUDA tests for atomics tests * Enabled DX12 test for atomics-buffer.slang Not clear just yet how to implement that for CUDA - it will work with StructuredBuffer. * hasContent -> isNonEmpty * Remove unneeded comment. 2019-11-21T22:06:19+00:00 Tim Foley tfoleyNV@users.noreply.github.com 2019-11-21T22:06:19+00:00 urn:sha1:2ea64ff4f2c7c43b72ff24650330fca79a87500f The `TEST_INPUT` facility allows textual Slang test cases to provide two kinds of information to the `render-test` tool: 1. Information on what shader inputs exist 2. Information on what values/objects to bind into those shader inputs Under the first category of information, there exists supporting for attaching a `dxbinding(...)` annotation to a `TEST_INPUT` which seemingly indicates what HLSL `register` the input uses. There is a similar `glbinding(...)` annotation, used for OpenGL and Vulkan. It turns out that these annotations were, in practice, completely ignored and had no bearing on how `render-test` allocates or bindings graphics API objects. There was some amount of code attempting to validate that explicit registers/bindings were being set appropriately, but the actual values were being ignored. The visible consequence of the `dxbinding` and `glbinding` annotations being ignored is issue #1036: the order of `TEST_INPUT` lines was *de facto* determining the registers/bindings that were being used by `render-test`. This change simply removes the placebo features and strips things down to what is implemented in practice: the `TEST_INPUT` lines do not need target-API-specific binding/register numbers, because their order in the file implicitly defines them. I added logic to the parsing of `TEST_INPUT` lines to make sure I got an error message on any leftover annotations, and went ahead and systematicaly deleted all of the placebo annotations from our test cases. If we decide to make `TEST_INPUT` lines *not* depend on order of declaration in the future, we can build it up as a new and better considered feature. The main alternative I considered was to keep the annotations in place, and change `render-test` and the `gfx` abstraction layer to properly respect them, but that path actually creates much more opportunity for breakage (since every single test case would suddenly be specifying its root signature / pipeline layout via a different path using data that has never been tested). The approach in this change has the benefit of giving me high confidence that all the test cases continue to work just as they had before. 2018-05-29T18:39:55+00:00 Tim Foley tfoleyNV@users.noreply.github.com 2018-05-29T18:39:55+00:00 urn:sha1:e7a83323bfc4dd698ef491375a37c65c83915951 Fixes #581 This change adds a new parameter passing mode `__ref` to exist alongisde `in`, `out`, and `inout`. The `__ref` modifier indicates true by-reference parameter passing (whereas `inout` is copy-in-copy-out). This is not intended to be something that users interact with directly, but rather a low-level feature that lets us provide a correct signature for the `Interlocked*()` operations in the standard library. Most of the support for passing what are logically addresses around already exists in the IR, so the majority of the work here is just in introducing the new type `Ref<T>` and then using it appropriately when lowering `__ref` parameters/arguments to the IR.