I need help diagnosing an error.

I am on ubuntu 23.10.

GL_VENDOR : AMD
GL_RENDERER : Radeon RX 5500 XT (navi14, LLVM 17.0.4, DRM 3.56, 6.5.0-44-generic)
GL_VERSION : 4.6 (Compatibility Profile) Mesa 23.3.0-devel
GLSL VERSION: 4.60

glCompileShader segfaults in fragment shader when using samplerCube with a uvec2 bindless texture handle.

Funny thing is all the shaders I am using with sampler2D with a uvec2 bindless texture handle work as expected. I am totally stopped from all progress until this is cleared. I am suspecting a mesa update did this, but I don't know enough to diagnose it. I want to emphasize , one day all my shaders worked and then the next , this error. ( Which means I did not edit any of my code to cause this error. )

dmesg has an error:

segfault at 0 ip 00007344e6a84680 sp 00007ffeef624b30 error 4 in radeonsi_dri.so[7344e6a7e000+e27000] likely on CPU 7 (core 7, socket 0)

What I have tried already: I have changed to a different known working video card. ( no-go ) I have used a backup drive that had the same code on it and it works. The backup drive had the same exact Mesa version on it. It has to be software related because when I swap to the backup drive, the shaders compile. I installed the latest radeon drivers from AMD and that did not fix it either. Also, I checked the return values of the GL_ARB_bindless_texture and I am not returing null.

FRAGMENT SHADER SOURCE:

const char* fragment_shader_source =
"#version 450 core\n"
"#extension GL_ARB_bindless_texture : require\n"

"in vec3 Normal;\n"
"in vec2 TexCoord;\n"
"in vec3 FragPos;\n"

"out vec4 FragColor;\n"

"uniform vec3 view_position;\n"
"uniform uvec2 reflection_map_bindless_texture;\n"
// works(1)"uniform samplerCube cubemap;\n"


"void main(){\n"
    "vec3 I = normalize( FragPos - view_position );\n"
    "vec3 R = reflect( I , normalize( Normal ) );\n"
    "FragColor = texture( samplerCube( reflection_map_bindless_texture ) , R );\n"
    // works(1)"FragColor = texture( cubemap , R );\n"
"}\n";

I hope someone else has seen this and can tell me what is happening. Or maybe can point me in right path to solving this.

You need 64 bit integers for bindless textures. And as far as I remember uvec2 is not 64 bits, except if you use it as the whole type.

Try this: layout(bindless_sampler) uniform sampler2D bindless;

But this is strange that this could cause a segfault in shader compilation… Maybe a regression in Mesa. Just contact them.

EDIT: I'm facing awfull issues when editing my post : content disappears.

Yup, these webpage editors are always for choice!

Can you really contact them? I put a post on:

https://gitlab.freedesktop.org/mesa/mesa/-/issues/11648

I received a quick response speculating that it might be related to another bug , but no solution or workaround.

As stated above, the sampler2D uniform variables are working. It is the samplerCube type that is not performing a conversion from the uvec2. We are using glProgramUniform2u to send the uvec2 to the fragment shader.

‘samplerCube( uvec2 )’ is supposed to , ( and always has previoulsly ) converted the uvec2 into a 64bit bindless texture handle. That functionality is now ( I believe ) causing the segmentation fault.

In the above ‘layout(bindless_sampler) uniform sampler2D bindless;’:

I think you are hard coding the location in the shader with a value passed into bindless_sampler?

Also , where is ‘bindless’ coming from ?

And , did you mean sampler2d?

Thanks.

I'm not sure if this is pure valid GLSL. This extension offers reall 64 bit integer support for GLSL. You really should prefer it.

What I was meaning with talking to the Mesa developers is asking why your code is segfaulting while doing the compilation. You could end up with errors, but not a segmentation fault. The previous behavior when it wasn't crashing was the right behavior. The only mean such functions could crash is when they don't point to the right address.

Anyway, I'm pretty sure Mesa tests carefully bindless textures when doing FS compilations. Maybe not all the situations, but at least all the working ones. So you don't need a workaround, only stick to a valid and conforming way to point to such textures.

Tyranna said:
I think you are hard coding the location in the shader with a value passed into bindless_sampler?

This is a uniform. You can hardcode the value or pass it in your host code like for any other uniforms.

Can you really contact them?

Yes. This is the only way to report bugs, asks for specific things and so on.

At https://www.khronos.org/opengl/wiki/Sampler_(GLSL)

under:

Version 4.20 binding

it looks like what you are talking about , but this is about assigning a texture unit to the sampler…

and,

I tried with that extension as well , and it fails too

GL CALLBACK: ** GL ERROR ** type = 0x824c , severity = 0x9146 , message = 0:13(22): error: sampler and image types can only be converted from a pair of 32-bit unsigned integers
Segmentation fault (core dumped)

const char* fragment_shader_source =

"#version 450 core\n"

“#extension GL_ARB_bindless_texture : require\n”

"#extension GL_ARB_gpu_shader_int64 : require\n"

"in vec3 Normal;\n"

"in vec2 TexCoord;\n"

"in vec3 FragPos;\n"

"out vec4 FragColor;\n"

"uniform vec3 view_position;\n"

"uniform uint64_t reflection_map_bindless_texture;\n"

"void main(){\n"

"vec3 I = normalize( FragPos - view_position );\n"

"vec3 R = reflect( I , normalize( Normal ) );\n"

"FragColor = texture( samplerCube( reflection_map_bindless_texture ) , R );\n"

"}\n";

_Silence_ said:
This is a uniform. You can hardcode the value or pass it in your host code like for any other uniforms.

Ok, but from what I read , the ‘uniform’ in that statement sets the texture unit that the texure is bound to , not the bindless texture handle. I do not think that has anything to do with the conversion the samplerCube is doing ( or not doing in this case… ). Also, I do not set the value of the texture unit, because they are bindless. The only time I use a texture unit per se is when I create the texture , and use glActiveTexture( GL_TEXTURE0 ); I beleive that it stores that data in the texture.

_Silence_ said:
Yes. This is the only way to report bugs, asks for specific things and so on.

Does you mean using the 'report a bug ‘ function at FreeDesktop.org , or do you have their tech’s phone number…

Tyranna said:
I tried with that extension as well , and it fails too GL CALLBACK: ** GL ERROR ** type = 0x824c , severity = 0x9146 , message = 0:13(22): error: sampler and image types can only be converted from a pair of 32-bit unsigned integers Segmentation fault (core dumped)

I think we are progressing. I guess that what you reported does not exactly correspond to what is happening. There are errors when compiling the shader. Likely, the shader does not exist, thus it might explain the crash you're encountering (to be validated with your previous experience).

From the OpenGL wiki:

If you have access to NV_vertex_attrib_integer_64bit or ARB_gpu_shader_int64, then you can use the uint64_t type in the shader. This can be used as integer values for inputs and outputs (including being fed by vertex attributes).

They can also be used in Interface Blocks. They have a size of 8 bytes, and in std140/430 layout, they have an alignment of 8 bytes.

uint64_t values can be converted to any sampler or image type using constructors: sampler2DArray(some_uint64). They can also be converted back to 64-bit integers.

Tyranna said:
it looks like what you are talking about , but this is about assigning a texture unit to the sampler…

You're using blindless textures, don't you ? So you have direct access to the sampler, not through any texture units.

Tyranna said:
Does you mean using the 'report a bug ‘ function at FreeDesktop.org , or do you have their tech’s phone number…

I'm not really sure about how to interprete this. You know, I'm the one trying to help here…

_Silence_ said:
I'm not really sure about how to interprete this. You know, I'm the one trying to help here…

That was a serious question, i thought maybe you knew of a way other that reporting a bug and waiting. I thought you may have meant actually talking to the devs. I am not intenting anything bad.

_Silence_ said:
You're using blindless textures, don't you ? So you have direct access to the sampler, not through any texture units.

That is correct.

_Silence_ said:
I guess that what you reported does not exactly correspond to what is happening.

I think the original description is accurate. However, if I use the original shader source ( from the original post ) , then there is no error, it must segfault before an error can be generated.

_Silence_ said:
Likely, the shader does not exist,

I am not sure what you mean by that. Can you explain?

Tyranna said:
I am not sure what you mean by that. Can you explain?

If the shader compilation / link fails, then your shader is not valid. Thus it is possible to face issues at other parts of your program that might explain your crash.

Tyranna said:
it must segfault before an error can be generated

You don't get the log from the same function than the one that compiles. As previously said, glCompileShader should not crash if it points to the right address location. So, if you're really sure that the crash happens on glCompileShader, then report a bug to Mesa (on freedesktop, that is, no other means are official, thus won't be accepted).

Debug your program and you'll most probably know exactly where it crashes.