Making it easier to work with shaders https://git.yummers.dev/slang.git/atom?h=master 2025-02-28T01:52:14+00:00 2025-02-28T01:52:14+00:00 Devon devonrutledge03@gmail.com 2025-02-28T01:52:14+00:00 urn:sha1:cd20e94af9f384c03e8be69f6c8ce9e97212cc9b * Add inner texture type to reflection json * Add expected result of test * Adjust test expected results * Fix ci test result --------- Co-authored-by: Yong He <yonghe@outlook.com> 2024-12-21T16:14:56+00:00 Stan 109335133+stanoddly@users.noreply.github.com 2024-12-21T16:14:56+00:00 urn:sha1:76fdeaa477a5d21176facf0296f77e28e2d59477 2023-11-02T04:42:12+00:00 Yong He yonghe@outlook.com 2023-11-02T04:42:12+00:00 urn:sha1:6aca3813c4ccc496c0f9b2db293acb546aa11d2d * Parameter binding and gfx fixes. * Add diagnostics on entry point parameters. * Fix. --------- Co-authored-by: Yong He <yhe@nvidia.com> 2020-01-08T22:45:06+00:00 Tim Foley tfoleyNV@users.noreply.github.com 2020-01-08T22:45:06+00:00 urn:sha1:0a856f458ff9f17d76bc646d008602713c6c66d1 This change adds some new entry points to the reflection API to cover corner cases that a majority of applications won't care about. These are most likely to come up for users who want to make a complete copy of the Slang reflection information into a data format of their own design. All of the information is stuff that we already computed as part of layout, and just hadn't exposed: * Alignment information for type layouts. This is only useful for ordinary/uniform data; in all other cases alignment is always one. Even for uniform/ordinary data, it is unlikely that any application would actually make use of it. * Layout information for the result of an entry point function. This would be useful for applications that need to enumerate the varying outputs (user- or system-defined) of a shader. Having information available for `out` parameters but not the function result was inconsistent. * The "element type" of a parameter block type (e.g., going from `ParameterBlock<X>` to `X`). This seems to have been an oversight since `ConstantBuffer<X>` appears to have been implemented, and the case for a type *layout* was handled. * The "container" variable layout for a parameter block or constant buffer. It took a while for us to arrive at the current representation of layout for parameter groups, and most client code continues to use the original API that requires us to generated kludged "do what I mean" data. However, if we don't expose the more useful new representation fully, there is no way for users to take advantage of it! The reflection test tool has been updated to print the new information where it makes sense, which provides us some level of coverage for the new code. Unfortunately, this led to some cascading changes: * First, a bunch of the tests had their output changed since they include new information. That's the easy bit. * Next, the "container" and "element" var layouts don't actually have names (because there is no actual variable underlying them), which means that the code to emit variable names in the JSON dump needed to be condition. * Making the `"name"` output conditional messed up a lot of the delicate logic that had been dealing with when to emit commas for the output JSON (JSON uses commas as separators, and doesn't allow trailing commas). I added a bit of new infrastructure to make it simple(-ish) to track when a comma actually needs to be output. 2019-03-25T19:36:41+00:00 Tim Foley tfoleyNV@users.noreply.github.com 2019-03-25T19:36:41+00:00 urn:sha1:3ae31a6ed8d79c23b2ab5a7d7d755dd7e42618f7 If the user declares global shader parameters for D3D SM5.1+ or Vulkan, then they need to go into an appropriate `space` or `set`: ```hlsl Texture2D t; // should go in space/set 0 SamplerState s; // same here... ``` This also applies to allocation of spaces/sets to parameter blocks: ```hlsl ParameterBlock<X> x; // should get space/set 0 ParameterBlock<Y> y; // should get space/set 1 ``` In cases where there are a combination of explicitly and implicitly bound parameters, anything left implicitly bound goes into a "default" space/set: ``` ParameterBlock<X> x : register(space0); // this has claimed space/set 0 Texture2D t; // this needs a space, so a "default" space/set of 1 will be claimed SamplerState s; // this also needs a space/set, and will use the default ``` The logic for deciding when a default space/set was needing was, more or less, looking at all the global shader parameters and seeing if any of them needed a `register`/`binding`, and if so determining that a default space /set would be needed. There was a bug in that logic, though, because of cases like the following: ```hlsl ParameterBlock<X> x; Texture2D t : register(t0, space99); ``` In this case, the parameter `t` already has an explicit binding, so it doesn't actually need a default space to be allocated. If we allocate a default space/set of 0 on the basis of `t`, then `x` will end up being shifted to space/set 1. The fix is to only consider global parameters that need `register`s/`binding`s *if* they don't have an explicit binding already (which is luckily something we are tracking during parameter binding). Note: just to clarify the behavior here, the "do we need a default space/set?" logic is done *before* automatic binding of parameters, so in a shader with any global texture/buffer/sampler parameters, those will all end up in space/set zero (in the absence of explicit bindings), and explicit blocks will start at space/set one, independent of the order of declaration. This behavior is maybe too subtle, and we might decide we need to change it, but it will have to do for now.