More concerns with storage classes

[mmoult]

I was reading through the chapter on Storage Classes (https://github.com/KhronosGroup/SPIRV-Guide/blob/main/chapters/storage_class.md), and I have questions about Uniform vs UniformConstant. Specifically, the chapter claims that:

Uniform is read-only

but I haven't found that to be totally accurate, nor do I see support for that assertion in the SPIR-V spec (which instead calls UniformConstant data read-only).

Consider this GLSL shader:

#version 450
layout (local_size_x = 1, local_size_y = 1, local_size_z = 1) in;

struct Particle {
    float position;
    float velocity;
};

layout(std140, binding = 1) buffer ParticleIO {
    Particle particles[];
};

void main() {
    const float location_bound = 100;
    float result = particles[gl_GlobalInvocationID.x].position
                 + particles[gl_GlobalInvocationID.x].velocity;
    particles[gl_GlobalInvocationID.x].position = result;
}

When it is translated to SPIR-V 1.2, we see:
%_ = OpVariable %_ptr_Uniform_ParticleIO Uniform

and later:

         %74 = OpAccessChain %_ptr_Uniform_float %_ %int_0 %71 %int_0
               OpStore %74 %73

Thus, the uniform variable is not read-only (unless the glslang translation was incorrect).

This begs a follow-up question: why not use a UniformConstant in this case? The chapter says:

UniformConstant can be viewed as a "opaque handle" to images, samples, raytracing acceleration structures, etc variables.

It seems like this is a case which belongs neatly with that enumeration.

I am having a hard time coming up with a solid mental model / abstraction for the two storage classes. The SPIR-V spec says that UniformConstant is read-only, but that is complicated by the fact that only the handle itself is read-only. This guide says that Uniform is read-only, but this issue appears to be another complication to that rule. If both Uniform and UniformConstant are read-only handles, what differentiates them?

[spencer-lunarg]

When it is translated to SPIR-V 1.2, we see:

So this is a pre-Vulkan 1.1 (SPIR-V 1.3) issue where the Uniform is used with a BufferBlock decorated Block and the spec says

When the type is used for a variable in the Uniform Storage Class the memory interface is a StorageBuffer-like interface, distinct from those variables decorated with Block. In all other Storage Classes the decoration is meaningless.

So this is deprecated and glslang will produce StorageBuffer here if targeting SPIR-V 1.3 and up

I am having a hard time coming up with a solid mental model / abstraction for the two storage classes (UniformConstant/Uniform).

@dneto0 or @alan-baker might be able to help here