diff options
| author | Tim Foley <tfoley@nvidia.com> | 2017-07-18 07:49:33 -0700 |
|---|---|---|
| committer | Tim Foley <tfoley@nvidia.com> | 2017-07-18 12:58:48 -0700 |
| commit | 1c022e2c3654de868c45658683f9e04cf4d68cc0 (patch) | |
| tree | d4a5f0cefd50c96aaf22921f9fef715b6359c0c5 /tests/rewriter | |
| parent | 361e29572ff8e2cdd1e4ffe2cb62599e9ef06461 (diff) | |
Support scalarization of varying input/output for GLSL
GLSL technically supports varying (`in`, `out`) parameters of `struct` type, but there are some annoying constraints (not allowed for VS input), and it doesn't work with how an HLSL user would usually put "system-value" inputs/outputs into a `struct` together with ordinary inputs/outputs.
To work around this, this change adds support for using an imported Slang `struct` type for an `in` or `out` parameter, in which case it will (1) be scalarized and (2) will have system-value semantics mapped appropriately, just as for an entry-point parameter when cross-compiling an HLSL-style `main()`.
Changes:
- Add a notion of a `VaryingTupleExpr` and `VaryingTupleVarDecl`, similar to those for the resources-in-structs case
- Trigger use of these when we have a global-scope varying in/out using an imported `struct` type
- Also use these in the cross-compilation case for ordinary varying input/output (since this approach seems like it should be more general, and can hopefully handle stuff like GS input/output some day)
- When generating parameter binding information, special case global-scope input/output, and treat it the same as entry-point-parameter input/output
- Revamp how used resource ranges are computed so that we can eventually make this specific to an entry point
- Actually implement first signs of life for `maybeMoveTemp` so that assignments to the tuple-ified outputs will work better
- Add first test case that actually seems to work
- Add diagnostics for conflicting explicit bindings on a parameter
- Add diagnostic for different parameters with overlapping bindings
- Make global-scope varying input/output use a tracking data structure specific to the translation unit for computing locations (so that they are independent of other TUs)
Diffstat (limited to 'tests/rewriter')
| -rw-r--r-- | tests/rewriter/varying-struct.slang | 21 | ||||
| -rw-r--r-- | tests/rewriter/varying-struct.vert | 54 |
2 files changed, 75 insertions, 0 deletions
diff --git a/tests/rewriter/varying-struct.slang b/tests/rewriter/varying-struct.slang new file mode 100644 index 000000000..92e9dda2e --- /dev/null +++ b/tests/rewriter/varying-struct.slang @@ -0,0 +1,21 @@ +//TEST_IGNORE_FILE: + +struct VS_IN +{ + float4 x : X; + float4 y : Y; +}; + +struct VS_OUT +{ + float4 color : COLOR; + float4 posH : SV_Position; +}; + +VS_OUT doIt(VS_IN i) +{ + VS_OUT o; + o.color = i.x; + o.posH = i.y; + return o; +} diff --git a/tests/rewriter/varying-struct.vert b/tests/rewriter/varying-struct.vert new file mode 100644 index 000000000..74ca8be37 --- /dev/null +++ b/tests/rewriter/varying-struct.vert @@ -0,0 +1,54 @@ +#version 450 core +//TEST:COMPARE_GLSL: + +#if defined(__SLANG__) + +__import varying_struct; + +in VS_IN foo; +out VS_OUT bar; + +void main() +{ + bar = doIt(foo); +} + +#else + +struct VS_IN +{ + vec4 x; + vec4 y; +}; + +struct VS_OUT +{ + vec4 color; + vec4 posH; +}; + +VS_OUT doIt(VS_IN i) +{ + VS_OUT o; + o.color = i.x; + o.posH = i.y; + return o; +} + +layout(location = 0) +out vec4 SLANG_out_bar_color; + +layout(location = 0) +in vec4 SLANG_in_foo_x; + +layout(location = 1) +in vec4 SLANG_in_foo_y; + +void main() +{ + VS_OUT SLANG_tmp_0 = doIt(VS_IN(SLANG_in_foo_x, SLANG_in_foo_y)); + SLANG_out_bar_color = SLANG_tmp_0.color; + gl_Position = SLANG_tmp_0.posH; +} + +#endif |
