diff options
| author | Tim Foley <tfoleyNV@users.noreply.github.com> | 2021-01-15 12:10:06 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2021-01-15 12:10:06 -0800 |
| commit | 2a5d5b32348c33aac7ca62aa9a4c2bb7cff8e08a (patch) | |
| tree | 01c394d8a3551d3e191e538d27b82472b721f749 /tests/language-feature/enums | |
| parent | f834f25794cfb746079e92d58c7410b767c57208 (diff) | |
Convert more tests to use shader objects (#1659)
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.
Diffstat (limited to 'tests/language-feature/enums')
| -rw-r--r-- | tests/language-feature/enums/enum-equality.slang | 2 | ||||
| -rw-r--r-- | tests/language-feature/enums/explicit-tag-type.slang | 2 | ||||
| -rw-r--r-- | tests/language-feature/enums/nested-enum.slang | 2 |
3 files changed, 3 insertions, 3 deletions
diff --git a/tests/language-feature/enums/enum-equality.slang b/tests/language-feature/enums/enum-equality.slang index 0ad39c0f4..d3a2aa4fd 100644 --- a/tests/language-feature/enums/enum-equality.slang +++ b/tests/language-feature/enums/enum-equality.slang @@ -3,7 +3,7 @@ // Test that equality (and inequality) of `enum` // types works as expected. -//TEST(compute):COMPARE_COMPUTE: +//TEST(compute):COMPARE_COMPUTE: -shaderobj enum Channel { diff --git a/tests/language-feature/enums/explicit-tag-type.slang b/tests/language-feature/enums/explicit-tag-type.slang index b55266fcb..52067bd3b 100644 --- a/tests/language-feature/enums/explicit-tag-type.slang +++ b/tests/language-feature/enums/explicit-tag-type.slang @@ -2,7 +2,7 @@ // Test that the underlying "tag type" of an `enum` can be set. -//TEST(compute):COMPARE_COMPUTE: +//TEST(compute):COMPARE_COMPUTE: -shaderobj enum Channel : uint { diff --git a/tests/language-feature/enums/nested-enum.slang b/tests/language-feature/enums/nested-enum.slang index 942a9e72d..ecc854440 100644 --- a/tests/language-feature/enums/nested-enum.slang +++ b/tests/language-feature/enums/nested-enum.slang @@ -2,7 +2,7 @@ // Test enums defined nested in a struct work as expected. -//TEST(compute):COMPARE_COMPUTE: +//TEST(compute):COMPARE_COMPUTE: -shaderobj struct Outer { |