Making it easier to work with shaders https://git.yummers.dev/slang.git/atom?h=master 2024-11-06T11:14:35+00:00 2024-11-06T11:14:35+00:00 Anders Leino aleino@nvidia.com 2024-11-06T11:14:35+00:00 urn:sha1:f8294202ce8d5658f6308eeaed634058db9bbb4b Structured buffer types translate to array types in the WGSL emitter. WGSL doesn't allow passing runtime-sized arrays to functions. Similarly for pointers to texture handles. Also, structured buffers (runtime-sized arrays) cannot be returned in WGSL. This closes issue #5228, issue #5278 and issue #5288 by enabling specialized functions to be generated in these cases, in order to work around these constraints. 2024-10-15T16:11:53+00:00 Anders Leino aleino@nvidia.com 2024-10-15T16:11:53+00:00 urn:sha1:9e3b0367cfd63f21a0519b61b6fd13e94dac1c51 2024-06-10T20:28:36+00:00 skallweitNV 64953474+skallweitNV@users.noreply.github.com 2024-06-10T20:28:36+00:00 urn:sha1:712ce653d4c3d7284dd71389f31540d0da7f144e 2024-06-07T07:28:16+00:00 skallweitNV 64953474+skallweitNV@users.noreply.github.com 2024-06-07T07:28:16+00:00 urn:sha1:004fe27a52b7952111ad7e749397aeff499de7ed 2023-08-08T05:23:31+00:00 Theresa Foley 10618364+tangent-vector@users.noreply.github.com 2023-08-08T05:23:31+00:00 urn:sha1:0b2d7533d475a4853a9c8fbc14537a1a8ec2c3f6 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 <yonghe@outlook.com> 2023-06-29T21:23:35+00:00 Yong He yonghe@outlook.com 2023-06-29T21:23:35+00:00 urn:sha1:47d0e8abe4f2fe3c2eede35079676210d1db0b1a Co-authored-by: Yong He <yhe@nvidia.com> 2023-06-26T22:18:06+00:00 Yong He yonghe@outlook.com 2023-06-26T22:18:06+00:00 urn:sha1:4c9e4de4b68f2612a39e8783e9da89605ecf54e0 * Fix DCE on mutable calls in a loop. * More accurate in-loop test. * code review fixes. * Fix. --------- Co-authored-by: Yong He <yhe@nvidia.com> 2022-09-05T20:57:06+00:00 Yong He yonghe@outlook.com 2022-09-05T20:57:06+00:00 urn:sha1:61ff1ba8459d70cbc887040c530b5ce1a125ec77 Co-authored-by: Yong He <yhe@nvidia.com> 2022-08-18T06:08:34+00:00 Yong He yonghe@outlook.com 2022-08-18T06:08:34+00:00 urn:sha1:adaea0e993fd8db351b5dad92802e47ed6d0ec77 * 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> 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.