Add a new GL_EXT_dynamically_uniform_attribute extension that introduces a variable declaration, function parameter, and function return type attribute [[dynamically_uniform]] to signify that the value is uniform across the shader.

This maps to the SPIR-V Uniform decoration.

The text makes clear that we need to validate the work group size in compile time, so that would exclude variable size work groups.

If that's not the case, what to do when the size is set to something that don't follow the rules for the given arrangement?

Adding a clarification about this could be nice. (Same comment applies to the corresponding SPV spec)

From https://github.com/KhronosGroup/glslang/issues/1300:

• Generally, an array declared as explicitly-sized cannot be redeclared without a size
• Tessellation evaluation and control shaders pre-declare gl_in as gl_in[gl_MaxPatchVertices]
• A later example of redeclaring gl_in uses gl_in[], which seems okay for geometry shading, but not for tessellation

Now, the purpose of redeclaring a built-in block is to subset its members, not establish array size. So, it could be tolerated to redeclare gl_in[] even if it was pre-declared with a specific size.

Or, we could be firm that it needs a size, and must be redeclared as gl_in[gl_MaxPatchVertices].

One question is how have drivers interpreted the specification? As, I think, the specification could be clarified in either direction. We would then ensure glslang follows suit.

Another question is whether another part of the specification already makes this more clear.

(Currently, glslang is narrow, requiring the explicit redeclaration, which seems quite intentional, as the check is specific to built-in block redeclarations.)

The amount of interface blocks used in compute shaders such as uniform blocks and shader storage blocks are currently limited by GL_MAX_COMPUTE_UNIFORM_BLOCKS and GL_MAX_COMPUTE_SHADER_STORAGE_BLOCKS respectively. The constraints lay around 8 for shader storage blocks and 15 for uniform blocks on most modern GPUs which is inadequate. It would be very useful if some extension were added increasing these constraints.

The GLSL spec isn't very clear if a control barrier is all that is needed to synchronize access to shared memory in compute shaders. There are two options:

• barrier() synchronizes execution order and makes writes to shared memory visible to other invocations with the local work group,
• barrier() synchronizes execution and additionally memoryBarrierShared() is required in order to make memory writes visible to other invocations within the local work group.

There is language in the GLSL spec (section 8.16 Shader Invocation Control Functions) that says:

The function barrier() provides a partially defined order of execution between shader invocations. This ensures that values written by one invocation prior to a given static instance of barrier() can be safely read by other invocations after their call to the same static instance barrier().

The above quotation suggests that barrier() is sufficient to synchronize access to shared memory in compute shaders. It's worth to mention that this language was initially introduced in ARB_tessellation_shaders.

On the other hand, the SPIR-V spec states explicitly that control barriers make writes visibile only for tessellation shaders:

When used with the TessellationControl execution model, it also implicitly synchronizes the Output Storage Class: Writes to Output variables performed by any invocation executed prior to a OpControlBarrier will be visible to any other invocation after return from that OpControlBarrier.

So, are memoryBarrierShared() barriers required together with control barriers in compute shaders in order to make memory writes visible to other invocations within the local work group? Is SPIR-V different than GLSL?

This extension is open for discussion, which can be held here in this pull request.

Basically, it adds control-flow hints (very strong suggestions). E.g.,

        [[unroll]]               for (int x = 0; i < 8; ++i) { ... }
        [[dont_unroll]]          while(...) { ... }
        [[dependency_infinite]]  do { ... } while(...);
        [[dependency_length(4)]] for (int x = 0; i < 8; ++i) { ... }
        [[flatten]]              if (...) { ... } else { ... }
        [[dont_flatten]]         switch(...) { ... }

See content of the extension for more detail. There is an implementation under way for this in glslang.

Consider this from 4.3.9:

Furthermore, if a matching block is declared as an array, then the array sizes must also match (or follow array matching rules for the shader interface between a vertex and a geometry shader).

Array matching rules are also different for TCS/TES stages. I'd suggest changing it to:

Furthermore, if a matching block is declared as an array, then the array sizes must also match, in accord with the array matching rules for the shader interface between the two stages.

Or something of the sort.

I address into glslang issue, but about spec issue... should be used any uint64_t or uvec2 with accelerationStructureEXT(accStructAddress) or not, with ray query compute shaders? Issue: https://github.com/KhronosGroup/glslang/issues/2903

Hi , I have a question about here's why not include the maximum number of uniform buffer or shader storage block bindings into the built-in constants. but i did find out some description at ogl4.5 spec and some cts test also test this feature. Is there any historical reason here? And I think their roles just like the built-in constants at ch7.3, ogl4.6 spec. Thank you.

ogl4.5 spec : chapter 4.4.5 Uniform and Shader Storage Block Layout Qualifiers

If the binding point for any uniform or shader storage block instance is less than zero, or greater than or equal to the implementation-dependent maximum number of uniform buffer bindings, a compile-time error will occur.

shader

ES31-CTS.functional.layout_binding.negative.ssbo.vertex_binding_over_max
layout(std140, binding = 8) buffer ColorBuffer0
{
       highp vec4 color1;
       highp vec4 color2;
} colors0;

The same conversion type is repeated.

https://github.com/KhronosGroup/GLSL/blob/7af180fd19879171437d0665b6622d14d0d83164/extensions/ext/GL_EXT_shader_explicit_arithmetic_types.txt#L505

 The following table shows allowed integral conversions:
      -------------------------------------------------------------------------
      | Type of    |     Can be implicitly converted to                       |
      | expression |                                                          |
      -------------------------------------------------------------------------
      | ...        |                                                          |
      | uint32_t   | uint64_t, uint64_t                                       |
      | ...        |                                                          |
      -------------------------------------------------------------------------

GLSL ES 3.10 says "Variables declared as shared may not have initializers and their contents are undefined at the beginning of shader execution.". Does the wording 'may not' means 'must not'?' It's actually allowed in many GL driver implementations per my observation, at least Linux INTEL/AMD/NVIDIA, and Windows NVIDIA. It would be better to have it clarified in spec. Thanks a lot!

Like I explained here #2870 it would be very nice to have symbolic and/or automatic differentiation in the language.

Example for how this could look like

float a = 3;
float b = a * a;
// db/da forward mode ad
float gradForward = forwardGrad(b, a);
// db/da backward mode ad
float gradBackward = backwardGrad(b, a);
// results should be: 
// b == 9
// forwardGrad == backwardGrad == 6

// same thing for vec or mat
vec3 c = vec3(2, 3, 4);
vec3 b = c * c;
// forward mode ad
// vec3(db0/dcX, db1/dcX, db2/dcX)
// (1 input -> 3 outputs)
vec3 gradForward0 = forwardGrad(b, c[0]);
vec3 gradForward1 = forwardGrad(b, c[1]);
vec3 gradForward2 = forwardGrad(b, c[2]);
// backward mode ad
// vec3(dbX/dc0, dbX/dc1, dbX/dc2)
// (3 input -> 1 outputs)
vec3 gradBackward0 = backwardGrad(b[0], c);
vec3 gradBackward1 = backwardGrad(b[1], c);
vec3 gradBackward2 = backwardGrad(b[2], c);
// b == (4, 9, 16)
// gradForward0 == gradBackward0 == (4, 0, 0)
// gradForward1 == gradBackward1 == (0, 6, 0)
// gradForward2 == gradBackward2 == (0, 0, 8)

The idea would be if these operations are encountered, the compiler would add the autodiff instructions required to the ast... Maybe having an OpForwardAD and OpBackwardAD would be even better, then this could be handled by the driver

Trivia:

1. Would to suggest the new vulkan descriptor model 2.0 (I have no any details, except raw binding, or using device address).
2. Would suggest to add new type: raw_buffer_t, raw_uniform_t, raw_shared_t, raw_texture_t, raw_image_t, etc.
3. raw_buffer_t, raw_uniform_t, raw_shared_t are similar to uint64_t, but with some rules, limitations and exceptions.
4. There data types respondent from real descriptor bindings. It may also need to be unified in some way.
5. The idea was also motivated by OpenCL.

Example:

layout(image_reference, rgba32f) uniform image2D imageRef;

layout(uniform_reference, scalar, uniform_reference_align = 16) uniform uniformRef {
   uvec4 data;
};

layout(buffer_reference, scalar, buffer_reference_align = 16) buffer bufferRef {
   uvec4 data;
};

layout(shared_reference, scalar, shared_reference_align = 16) shared sharedRef {
   uvec4 data;
};

layout(binding = 0) uniform raw_buffer_t buffers[]; // which can be handled similar alike buffer reference
layout(binding = 1) uniform raw_texture_t textures[]; // which can contain 2D, 3D, cubemap textures, etc.
layout(binding = 2) uniform raw_image_t images[];
raw_shared_t sharedMemory;

void main() {
  bufferRef buf = bufferRef (buffers[0]);
  texture2D tex = texture2D(textures[0]);
  sharedRef sbt = sharedRef(sharedMemory);
  imageRef imf = imageRef(images[0]);
  //vec4 imagePixel = imageLoad(imf, ivec2(coordinate));
}

Let me explain what this is all about:

1. raw_buffer_t, raw_uniform_t, raw_shared_t have a + byteOffset capability
2. References to these handles can be passed by function, with atomic operation capabilities
3. The real number is never known, they are actually virtual
4. Easier to debug because they are bound to descriptor binding, including the indexed model
5. You can check the presence of this binding (element), but again you can't know its number
6. You can't save them (those handles) to memory. You can only operate on them inside the shader.

Why did I still decide not to add the idea from shader model 6.6 in its entirety?

1. Backward compatibility with the current bindings model.
2. Avoiding some misunderstandings and conflicts in terms of typing.

And what will change?

1. Essentially the implementation of the pointer and reference model.
2. The ability to check for presence or empty binding.
3. Different data types for different purposes.
4. Ability to atomic operations on argument in functions.

Virtual device buffer address? Aka. shader model 6.6 miscellaneous. Not applicable everywhere. For example shared is more of a purely hardware thing, and it doesn't have a good binding.

// expose raw_buffer_t
struct VBA64 {
  uint32_t set_binding_index;  //de-facto device address of binding
  uint32_t byteOffset;
};

// expose raw_buffer_t (alt)
struct VBA64Indexed {
  uint16_t set_and_binding; //de-facto device address of binding
  uint16_t index; // if indexed
  uint32_t byteOffset;
};

// expose raw_shared_t
struct VSA32 {
  uint32_t byteOffset;
};

Safety. Stands between the physical device buffer address and the binding to the descriptor. And the same limit checks, validation, and debugging are available (though in bytes, in hex code). Even an availability check is available.

I still not seen no one pull requests, no issue tracking, no speaks or mentions... I think it's time to implement VK_KHR_shader_integer_dot_product in GLSL...? Looks like GLSL already died...

The spec is unclear whether memory decorated with writeonly can be passed to, for example, atomicAdd. The atomic operations are specifically described to read then write the memory in question, so it seem reasonable that either writeonly or readonly should be invalid. Section 8.11 (Atomic Memory Functions) goes to some effort to say that restrict, coherent, and volatile are valid, but it makes no mention of readonly or writeonly.

However, we have discovered that the GIANTS Editor does this in many of its shaders, and closed-source drivers from both AMD and NVIDIA accept the shaders.

See also https://gitlab.freedesktop.org/mesa/mesa/-/issues/5842.

In The OpenGL Shading Language, Version 4.60.7, section 8.9.2. Texel Lookup Functions the parameter P is missing a type in the gsampler3D overload of textureGrad

gvec4 textureGrad(gsampler3D sampler, P, vec3 dPdx, vec3 dPdy)
                                      ~ missing parameter type 'vec3'

In section 8.12, Image Functions one of the overloads of imageSize is listed with the type gimageRect which does not exist. The correct parameter type should be gimage2DRect

ivec2 imageSize(readonly writeonly gimageRect image)
                                   ~~~~~~~~~~ should be gimage2DRect