| Age | Commit message (Collapse) | Author |
|---|
|
This is functionality required to support a Falcor bug fix.
Most of the code to compute the right semantic name/index for a parameter was already present.
This change adds:
- Storage for semantic name/index on every `VarLayout`
- Note: this is wasteful and should be optimized later
- A public API to query the semantic name/index
- The contract is that this API returns `NULL` if the parameter had no semantic
- A bit of work in `parameter-binding.cpp` to attach semantics to varying input/output when traversing varying parameters.
- Note: this is intentionally set up so that it associates semantics even with non-leaf parameters, so that an API user can query the semantic of a `struct` parameter and know that its members will be assigned sequential semantic indices from its starting value.
- Support for dumping this information in reflection tests
One notable thing that I did *not* change here is that the reflection test fixture doesn't report information on the output of an entry point, even though it really should. That should be fixed in a separate change, though, because it would affect many of the expected outputs.
|
|
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)
|
|
Fixes #15
These are the modifiers like:
layout(local_size_x = 16) in;
Unlike the HLSL case, these don't get attache to the entry point function itself, so there is a bit more work involed in looking them up.
Just to make sure I didn't mess up the HLSL case, I went ahead and added two tests for this capability: one for GLSL and one for HLSL.
|
