Open null77 opened 6 years ago
Assigned to @johnkslang to investigate the SPIR-V side. Based on that we can decide what to do with GL_KHR_vulkan_glsl.
Where did the idea come from that SPIR-V could not support it? I don't see SPIR-V putting any constraints on this, as is appropriate, so that the client API can set it's own rules.
For example, the Vulkan specification says, in the section "Attribute Location and Component Assignment", effectively that attribute aliasing is not allowed:
Location aliasing is causing two variables to have the same location number. Component aliasing is assigning the same (or overlapping) component number for two location aliases. Location aliasing is allowed only if it does not cause component aliasing. Further, when location aliasing, the aliases sharing the location must all have the same SPIR-V floating-point component type or all have the same width integer-type components.
If OpenGL and GLSL still allow it for some situations, I think that is all fine and there are no issues.
I'll have to go back and investigate. I think the problem I was having was related to two attributes having the same location in GLSL and glslang having an issue or error.
Glslang is enforcing the rules, allowing aliasing for OpenGL desktop, but not for ES, and not when desktop GLSL is targeted to Vulkan SPIR-V.
I just tried these combinations with a shader, and they seem to be semantically checked correctly for each situation.
That is, I can get:
Decorate 9(a1) Location 1
Decorate 10(a2) Location 1
From:
#version 460
layout(location = 1) in vec4 a1;
layout(location = 1) in vec4 a2;
When targeting OpenGL with the SPIR-V.
Right. I think my suggestion was just that we should mention aliasing is not allowed in the "The following features are removed:" section of the GL_KHR_vulkan_glsl extension spec.
Some versions of GLSL allow for attribute location aliasing - it seems this isn't supported in SPIR-V. It probably should be mentioned in the extension that it isn't accepted.