OpenGL & Vulkan

[nke]

With Adrenaline Edition 22.10.1 the unsized input variable arrays in geometry shaders don't work as specified in ARB_geometry_shader4 and produce a compiler error. The extension specification at https://registry.khronos.org/OpenGL/extensions/ARB/ARB_geometry_shader4.txt explicitly states the size for the array declaration is optional and the size usually is specified via glProgramParameter:

    Similarly to the built-in varying variables, user-defined input varying
    variables need to be declared as arrays. Declaring a size is optional. If
    no size is specified, it will be inferred by the linker from the input
    primitive type. If a size is specified, it has to be of the size matching
    the number of vertices of the input primitive type, otherwise a link error
    will occur. The built-in variable gl_VerticesIn, if so desired, can be
    used to size the array correctly for each input primitive
    type.

With Adrenaline Edition 22.5.1 unsized arrays still worked, Pro 22.Q3 works as well but 22.10.1 does not work . I did not try it but reading the release info I'd guess it broke with 22.7. Drivers from team green and blue also accept it.

Tiny test-case that demonstrates the issue on pastepin because the word filter here is rather aggressive and doesn't like my code for some reason: https://pastebin.com/SfKKQfu2

output:

vendor: ATI Technologies Inc.
version: 4.6.0 Compatibility Profile Context 22.10.1.221003
ERROR: 0:7: '[' :  array must be sized by a redeclaration or layout qualifier before being indexed with a variable
ERROR: 0:7: '' : compilation terminated
ERROR: 2 compilation errors.  No code generated.

ERROR: 0:6: 'variable indexing sampler array' : not supported with this profile: none
ERROR: 0:6: '' : compilation terminated
ERROR: 2 compilation errors.  No code generated.

There is also a change in what the compilers accept between driver versions when it comes to indexing uniform sampler arrays with older glsl versions. Old glsl specifications only allowed those arrays to be indexed with constant integral expression and newer versions allow dynamically uniform integral expression. In the example code it's the part below "//sampler array problem". It looks like now the compiler is using a stricter and more correct interpretation of the glsl spec for those old versions. Driver version 22.5.1 and previous drivers as well as the drivers from team green and blue accept dynamically uniform integral expression even with the old glsl versions. That change could break some older software.

[dipak]

Hi @nke ,

Thank you for reporting it and providing the reproducible test-case. I have whitelisted you for the AMD Devgurus community and moved the post to the OpenGL forum. I will report the issue to the OpenGL team.

Thanks.

[dipak]

A bug ticket has been created to track this issue. It would be helpful if you please provide the setup information like OS, GPU etc.

Thanks.

[nke]

On my system it is:

Edition Windows 10 Enterprise
Version 21H2
OS build 19044.2006
GPU is some Radeon RX 580

But I also know of a system with a RX 5000 series card with the same issue.

[nke]

gl_VerticesIn also looks also like it's not working correctly. If the array in my original snippet is sized with gl_VerticesIn the compiler accepts the code but once the array is accessed with an index greater zero I get

ERROR: 0:7: '[' :  array index out of range '1'
ERROR: 0:7: '' : compilation terminated
ERROR: 2 compilation errors.  No code generated.

#version 130
extension GL_ARB_geometry_shader4 : require
in float something[gl_VerticesIn];
void main(){
  float f0 = something[0];
  float f1 = something[1];
}

[dipak]

Hi @nke ,

The OpenGL team wants to check one point with you. For the sampler array case, would you suggest to relax rules for all the dynamically indexing cases in low version or just for uncalled functions like the example code?

[nke]

In my opinion it should either be relaxed in both cases or in none of them. My test case only has an unused function because it was just enough to reproduce the issue. The actual shader where I encountered the problem did use the problematic function.

With relaxed rules the compiler would accept invalid code if the older specifications are interpreted strictly, which is annoying when someone tries to write standard conforming code. If the rules aren't relaxed older software that was working just fine could break for all users. Both options are bad in different ways but personally I'd prefer the relaxed rules and not break things for users.

[dipak]

Thanks for your feedback. I will pass it on to the OpenGL team.

[dipak · Accepted solution]

Hi @nke ,

As I have been informed, the fix is already available in the recent drivers. Could you please try the latest driver and let us know if the issue has been fixed?

Thanks