https://github.com/shader-slang/slang
Revision abb020b15c4f1057657e5f8f63c02b15615bf6ec authored by Tim Foley on 25 March 2021, 23:40:17 UTC, committed by GitHub on 25 March 2021, 23:40:17 UTC
The original goal of this change was to streamline the `TEST_INPUT` system by eliminating options that are no longer relevant once we have eliminated the non-shader-object execution paths. The result is more or less a re-implementation/refactor of the logic around how input is parsed and represented, that tries to set things up for a more general sytem going forward.

The main changes isthat the `ShaderInputLayout` no longer tracks a simple flat list of `ShaderInputLayoutEntry` (that is a kind of pseudo-union of the various buffer/texture/value cases), and it instead uses a hierarchical representation composed of `RefObject`-derived classes to represent "values."

There are several "simple" cases of values

* Textures

* Samplers

* Uniform/ordinary data (`uniform`)

* Buffers composed of uniform/ordinary data (`ubuffer`)

Then there are composed/aggregate values that nest other values:

* An *aggregate* value is a set of *fields* which are name/value pairs. It can be used to fill in a structure, for example.

* An *array* value is a list of values for the elements of an array. It can be used to fill out an array-of-textures parameter, for example.

* A combined texture/sampler value is a pair of a texture value and a sampler value (easy enough)

* An *object* holds an optional type name for a shader object to allocate (it defaults to the type that is "under" the current shader cursor when binding), and a nested value that describes how to fill in the contents of that object

Finally there are cases of values that are just syntactic sugar:

* A `cbuffer` is just shorthand for creating an object value with a nested uniform/ordinary data value

The big idea with this recursive structure is that it gives us a way to handle more arbitrary data types with name-based binding. Supporting this new capability requires changes to both how input layouts get parsed, and also how they get bound into shader objects.

On the parsing side, things have been refactored a bit so that parsing isn't a single monolithic routine. The refactor also tries to make it so that the various options on an input item (e.g., the `size=...` option for textures) are only supported on the relevant type of entry (so you can't specify as many useless options that will be ignored).

The bigger change to parsing is that it now supports a hierarchical structure, where certain input elements like `begin_array` can push a new "parent" value onto a stack, and subsequent `TEST_INPUT` lines will be parsed as children of that item until a matching `end` item. This approach means that we can now in principle describe arbitrary hierarchical structures as part of test input without endlessly increasing the complexity of invididual `TEST_INPUT` lines.

On the binding side, we now have a central recursive operation called `assign(ShaderCursor, ShaderInputLayout::ValPtr)` that assigns from a parsed `ShaderInputLayout` value to a particular cursor. That operation can then recurse on the fields/elements/contents of whatever the cursor points to.

Major open directions:

* With this change it is still necessary to use `uniform` entries to set things like individual integers or `float`s and that is a little silly. It would be good to have some streamlines cases for setting individual scalar values.

* Further, once we have a hierarchical representation of the values for `TEST_INPUT` lines, it becomes clear that we really ought to move to a format more like `TEST_INPUT: dstLocation = srcValue;` where `srcValue` is some kind of hierarchial expression grammar. Refactoring things in this way should make the binding logic even more clear and easy to understand. The refactored parser should make parsing hierarchical expressions easier to do in the future (even if it uses the push/pop model for now)

* One detailed note is that the representation of buffers in this change is kind of a compromise. Just as an "object" value is a thin wrapper around a recursively-contained value for its "content" it seems clear that a buffer could be represented as a wrapper around a content value that could include hierarchical aggregates/objects instead of just flat binary data (this would be important for things like a buffer over a structure type that lays out different on different targets). The main problem right now with changing the representation is actually needing to compute the size of a buffer based on its content, so that can/should be addressed in a subsequent change.

Details:

* The base `RenderTestApp` class and the `ShaderObjectRenderTestApp` classes have been merged, since the hierarchy no longer serves any purpose.

* Disabled the tess that rely on `StructuredBuffer<IWhatever>` because they aren't really supported by our current shader object implementation

* Replaced used of `Uniform` and `root_constants` in `TEST_INPUT` lines with just `uniform`

* Removed a bunch of uses of `stride` from `cbuffer` inputs, where it wasn't really correct/meaningful

* Added the `copyBuffer()` operation to VK/D3D renderers, along with some missing `Usage` cases to support it.

* Made `ShaderCursor` handle the logic to look up a name in the entry points of a root shader object, rather than just having that logic in `render-test`. (We probably need to make a clear design choice on this issue)
1 parent e050035
History
Tip revision: abb020b15c4f1057657e5f8f63c02b15615bf6ec authored by Tim Foley on 25 March 2021, 23:40:17 UTC
Clean up render-test handling of input (#1766)
Tip revision: abb020b
File Mode Size
.github
build
docs
examples
external
extras
prelude
source
tests
tools
.editorconfig -rw-r--r-- 937 bytes
.gitattributes -rw-r--r-- 95 bytes
.gitignore -rw-r--r-- 1.0 KB
.gitmodules -rw-r--r-- 951 bytes
CODE_OF_CONDUCT.md -rw-r--r-- 3.1 KB
LICENSE -rw-r--r-- 1.1 KB
README.md -rw-r--r-- 8.6 KB
github_build.sh -rw-r--r-- 495 bytes
github_test.sh -rw-r--r-- 546 bytes
premake.bat -rw-r--r-- 120 bytes
premake5.lua -rw-r--r-- 48.2 KB
slang-com-helper.h -rw-r--r-- 4.8 KB
slang-com-ptr.h -rw-r--r-- 4.9 KB
slang-gfx.h -rw-r--r-- 49.7 KB
slang-tag-version.h -rw-r--r-- 36 bytes
slang.h -rw-r--r-- 168.7 KB
slang.sln -rw-r--r-- 17.9 KB
test.bat -rw-r--r-- 1.4 KB

README.md

back to top