| Age | Commit message (Collapse) | Author |
|---|
|
* Fix User Attribute string reflection
Fixes #6794
* Fix strings not being properly escaped
---------
Co-authored-by: Darren Wihandi <65404740+fairywreath@users.noreply.github.com>
Co-authored-by: Yong He <yonghe@outlook.com>
|
|
|
|
|
|
* Allow impliocit 'uniform' entrypoint parameters.
* Fix.
* Fix.
* Fix.
* Fix.
|
|
The syntax like:
[__AttributeUsage(_AttributeTargets.Var)]
[__AttributeUsage(_AttributeTargets.Param)]
struct DefaultValueAttribute
{
int iParam;
};
is allowed.
For user-defined attribute, we can specify more attribute targets on the
attribute declaration. So one attribute can be used in more than one
situations.
|
|
The reflection test doesn't print the user attributes decorating for
the variables, only types. Therefore, add the print for user attributes
of variables.
|
|
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.
|
|
|
