GL_EXT_vulkan_glsl_relaxed: need more detailed description

[chirsz-ever]

I have this questions:

https://github.com/KhronosGroup/GLSL/blob/5757aa6a24a1e92faeae29b0cc1d502c74ca2a78/extensions/ext/GL_EXT_vulkan_glsl_relaxed.txt#L91-L94

1. Will the order of members in this uniform block be guaranteed to the order of appearance? It's important to the memory layout.

2. Is "gl_DefaultUniformBlock" independent between stages? In other words, to keep the OpenGL semantics that uniforms are shared between shader stages, should developer update the uniform block buffers manually? Or the converted "gl_DefaultUniformBlock" always have different binding numbers?

https://github.com/KhronosGroup/GLSL/blob/5757aa6a24a1e92faeae29b0cc1d502c74ca2a78/extensions/ext/GL_EXT_vulkan_glsl_relaxed.txt#L105-L108

3. Is this totally appropriate? gl_*Index and gl_*ID have different meaning, which may affect the shader's behavior. IMO, the developer who want to reuse OpenGL GLSL in Vulkan could just apply these simple steps:
   1. If the base offset would always be 0, just replace gl_*ID with gl_*Index by defining macros:

      #ifdef VULKAN
      #define gl_VertexID gl_VertexIndex
      #define gl_InstanceID gl_InstanceIndex
      #endif

   2. If need a non-zero base offset, pass it by ways like uniform blocks or push constant or any method you like. Then replace gl_*ID by defining macros:

      #ifdef VULKAN
      layout(binding=1) uniform IndexBase {
        int VertexBase;
        int InstanceBase;
      };
      #define gl_VertexID (gl_VertexIndex - VertexBase)
      #define gl_InstanceID (gl_InstanceIndex - InstanceBase)
      #endif

      The VertexBase and the InstanceBase are corresponding base offsets. Whether the base offset is always 0 is only known by the developers, so I think the aliases of gl_*ID in GL_EXT_vulkan_glslrelaxed should be removed, for that it would case confusion between `glIndexandgl_ID`.

[chirsz-ever]

@mbechard Looking forward to your reply.

[mbechard]

Hey, thanks for your questions:

1. Will the order of members in this uniform block be guaranteed to the order of appearance? It's important to the memory layout.

Since there are no rules about how default uniforms would be grouped into a block, especially across multiple compilation units, there are no guarantees about their order within the block. It's expected you'd use reflection to determine their offset within the block. This is what I'm doing with my codebase that is using this extension, and things work nicely.

2. Is "gl_DefaultUniformBlock" independent between stages? In other words, to keep the OpenGL semantics that uniforms are shared between shader stages, should developer update the uniform block buffers manually? Or the converted "gl_DefaultUniformBlock" always have different binding numbers?

GLSL does not allows blocks with the same block name to have different definitions across different stages. To follow this rule, and to make the behavior a bit more GL-like, I would expect implementations of this extension to combine all default uniforms across all stages into one block that is identically declared for all stages. This is what GLSLang's implementation does.

3. Is this totally appropriate? gl_*Index and gl_*ID have different meaning, which may affect the shader's behavior. IMO, the developer who want to reuse OpenGL GLSL in Vulkan could just apply these simple steps:

Certainly it could be argued that this feature could have been omitted. However, one of the goals for this extension was to avoid needless preprocessor definitions in code , which could interact with other-programmer code that is also applying preprocessor definitions. IMO one of the faults of the original Vulkan-GLSL extension is that tied the GLSL programmers and the Vulkan programmer together more than they needed to be. This extension frees the GLSL programmer (who may be an artist with no other programming knowledge) from having to know about many Vulkan features such as sets and bindings or if their shader is even being consumed by Vulkan. It's up to the Vulkan programmer to provide a runtime environment for the shader to run appropriately. The Vulkan programmer should handle the case based on their understanding of how they are consuming GLSL shaders. If the GLSL is written without the knowledge that it's being consumed by Vulkan, then the Vulkan programmer should maintain 0 offsets for those IDs to provide a correct runtime environment for the shader.

Let me know if you have any other thoughts. Thanks for your feedback!

[chirsz-ever]

Thanks for the detailed reply! I totally get what I want. It would be nice if you have time to add them to the extension specification.