-
Notifications
You must be signed in to change notification settings - Fork 15
Description
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?