Consider the following code:
layout(constant_id=0) const int Y = 1;
layout(constant_id=1) const int Z = 2;
layout(constant_id=3) const int X = Y + Z;
Previously, it would produce SPIR-V decorations like this:
Decorate 21(Y) SpecId 1
Decorate 22 SpecId 3
Decorate 33(Z) SpecId 0
This seems inaccurate, since the spec constant `X` that is dependent on
the two others did not get a name in the SPIR-V decorations. This behavior
may potentially negatively affect shader introspection capabilities.
This change alters the behavior to always add a name, which results in the code
above producing the following decorations:
Decorate 21(Y) SpecId 1
Decorate 22(X) SpecId 3
Decorate 33(Z) SpecId 0
UniformAndStorageBuffer8BitAccess capability.
When using the 8-bit storage extension it basically always used the
`UniformAndStorageBuffer8BitAccess` capability, even in cases where it
wasn't required. For instance if we are targeting Vulkan 1.1 (SPIR-V 1.3
or higher), and we are only using 8-bit types in an SSBO, we only need
the `StorageBuffer8BitAccess` capability.
I fixed this by enabling storage buffer use in Vulkan 1.1 / SPIR-V 1.3
or higher, and then changing the logic to match.
I also added some tests that will output different capabilities when run
on Vulkan 1.0 and 1.1, thus they are added twice to the test list (one
for each version).
Fixes#1539
- Emit relevant capability/extension for use of perprimitiveNV in fragment shader
- Remove redundant checks for mesh shader qualifiers in glslang.y
- Add profile version check for use of extension GL_NV_mesh_shader
- Add a new gtest for use of perprimitiveNV in fragment shader
When capabilities are needed for specific SPIR-V instructions, it is
fragile to do so based on GLSL/AST usage; it should be based on actual
instructions they got translated to.
These introduce limited support for 8/16-bit types such that they can only be accessed in buffer memory and converted to/from 32-bit types.
Contributed from Khronos-internal work.
- Use much simpler method to update implicit array sizes.
The previous overly complicated method was error prone.
- Rationalize all use of unsized arrays.
- Combine decorations when generating SPIR-V, to simplify
adding extensions.
