For opaque types such as samplers, images, and atomic counters, we want to
reference the actual object in the child function. For a long time, we
used a shadow variable and made a copy of the image/sampler. In 76d0ac1a,
this was changed to not shadow samplers. However, this didn't cover all
opaque types and it also didn't get the pointer storage classes right.
This commit fixes both of these issues.
Fixes#324
The compiler will mark struct members with those builtins, but won't
declare the capability until that member is accessed by some executable
instruction.
Test changes:
- spv.430.vert: was missing ClipDistance capability.
- spv.precise.tese: remove TessellationPointSize capability.
The grammar now accepts type casts, like "(int)x", but that
has to be disambiguated from "(a + b)", needed deeper lookahead
and backing up than what existed so far.
This checkin implements about half of the HLSL intrinsics for a subset of their
entire type support (but a useful subset). The uncommented lines in
TBuiltInParseablesHlsl::identifyBuiltIns shows which are connected.
The test result should only give one error about linking
ES and non-ES shading language compilation units:
- empty.frag: No version info, interpreted as 100, ES
- empty2.frag: No version info, interpreted as 100, ES
- empty3.frag: Version declared as 110, non-ES
Previously, because the new intermediate is always created
without version/profile information, there would be two
linker errors:
1.) When merging the new intermediate with empty.frag
2.) When merging (new intermediate + empty.frag + empty2.frag) with empty3.frag
Now, there is only one error; as the error with merging the
new intermediate with empty.frag has been removed.
Note: This required adding a new test mode to see the AST for vulkan tests.
This also required reworking some deeper parts of type creation, regarding
when storage qualification and constness is deduced bottom-up or dictated
top-down.
GLSL interpolation qualifiers and auxiliary storage qualifiers are not
mutually exclusive. So when they are translated to SPIR-V decorations, two
independent utility methods should be employed to do this job.
Spec for decorating the OpVariable:
"The remaining variables listed by OpEntryPoint with the Input or Output storage class form the user-defined variable interface. These variables must be identified with a Location decoration"
Spec for decorating struct type:
"The layout of a structure type used as an Input or Output depends on whether it is also a Block (i.e. has a Block decoration).
If it is a not a Block, then the structure type must have a Location decoration"
These capabalities were added on declaration of the members, but
that is considered too aggressive, as those members are automatically
declared in some shaders that don't use them. Now, actual access
is needed to make the capabalities be declared.
