Add GL_EXT_relaxed_block_layout

[Karpov-Ruslan]

This extension is written to support VK_KHR_relaxed_block_layout Vulkan extension. Currently there is only VK_EXT_scalar_block_layout support - GL_EXT_scalar_block_layout. To correct this historical injustice, I present this extension.

If GLSL Working Group approves this extension, then I will create a PR in glslang (link to fully working fork with the extension implementation).

The example of usage GL_EXT_relaxed_block_layout:

#version 460 core

#extension GL_EXT_relaxed_block_layout : require

struct S {
    int i;  // Struct member offset: 0
    vec3 j; // Struct member offset: 4
};

layout(binding = 0, std430, relaxed) buffer SSBO {
    int a; // Offset: 0
    S s;   // Offset: 16 (the base alignment of structure equals to 16)
    int b; // Offset: 32 (the size of structure equals to 16)
};

void main() {...}

[CLAassistant]

All committers have signed the CLA.

[Karpov-Ruslan]

@gnl21 Could you take a look, please? If I've broken the established procedure for adding a new extension or if I don't have the rights to create an extension, please let me know.

[jeffbolznv]

It's not clear to me what the goal of this extension is. I think scalar block layout is supported basically everywhere at this point, so why not just use that?

[Karpov-Ruslan]

Thanks for reply!

1. VK_KHR_relaxed_block_layout is a part of Vulkan 1.1. As you can see, Vulkan 1.1 distribution is the highest:
   

   Of course, no one forbids using the VK_EXT_scalar_block_layout extension, however

2. Vulkan Spec notes that scalar block layout generally has lower performance compared to other alignments:
   

3. In my opinion, for almost every Vulkan feature that changes shaders, GLSL provides a corresponding extension. Since VK_KHR_relaxed_block_layout is also feature, then it has all rights to enter GLSL as an extension.

[gnl21]

It's worth noting, though, that gpuinfo has VK_EXT_scalar_block_layout at 83% support. That will include older reports from devices that have been updated or are no longer in the wild, so the figure for current devices will be higher. I don't know about the range of implementations in the wild, but I'd be surprised if any performance penalty would make it worth implementing the extension, and it could be worked around by placing members using the offset decoration if needed.

All of that doesn't take away from the extension's right to exist and one of the main blockers, having an implementation, is already clear. I guess the question is whether having this would make things more confusing for people looking at how to lay out their data when they might be better served by going straight to scalar layouts.

[Karpov-Ruslan]

... it could be worked around by placing members using the offset decoration if needed.

I would agree, but it seems that you can't use any layout qualifiers, including offset and align qualifiers on structures. Thus, when it comes to adjusting offsets in structures, the only way to change offsets is to use a packing qualifier in the interface block where this structure is used:

// Cannot change the offsets of structure members using the `offset` or `align` layout qualifiers.
struct S {
    int integer;
    vec2 vector2;
};

layout(set = 0, binding = 1, std430) buffer SSBO1 {
    S s[16]; // S::integer has an offset of 0, S::vector2 has an offset of 8, array stride is 16, total SSBO1 size is 256
} ssbo1;

layout(set = 0, binding = 2, scalar) buffer SSBO2 {
    S s[16]; // S::integer has an offset of 0, S::vector2 has an offset of 4, array stride is 12, total SSBO2 size is 192
} ssbo2;

(godbolt Example, SPIR-V output has the offsets)
So a workaround using offset decorations is not always possible.

I guess the question is whether having this would make things more confusing for people looking at how to lay out their data when they might be better served by going straight to scalar layouts.

I absolutely agree, scalar block layout is the most intuitive block layout. The relaxed block layout is a bit confusing, however the purpose of this extension is not to confuse, but rather to give developers the opportunity to use the most tightly packed block layout, provided that scalar block layout is not used due to possible performance degradation or lack of VK_EXT_scalar_block_layout extension on the device.