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

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.

Right. I got a bug report there already , but no information on what to do was offered. The link to that bug report is up above.

I am sure it segfaults on glCompileShader , but just on a fragment shader using a bindless texture handle passed to samplerCube as a uvec2. I believe the type converting function of samplerCube is damaged somehow. What I do not know is if the problem is local to my installation or Meas itself , or the X driver radeon_dri.so.

I do not really know how to diagnose it.

And thanks for the help O do appreciate it. Its not fun when you are stuck.

UPDATE: This was posted at freedesktop.org about my problem.

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

I do not know what that text is , maybe a debugger output?

Timothy Arceri @tarceri · 8 hours ago

Developer

I was wrong this is a different existing issue:

#0  ir_variable_replacement_visitor::visit_leave (this=0x7fffffffd1f0, ir=0xb569de0) at ../src/compiler/glsl/opt_function_inlining.cpp:425
#1  0x00007fffecee60f5 in ir_assignment::accept (this=0xb57e6f0, v=0x7fffffffd1f0) at ../src/compiler/glsl/ir_hv_accept.cpp:311
#2  0x00007fffecee5bcd in visit_list_elements (v=v@entry=0x7fffffffd1f0, l=l@entry=0x7fffffffd1d0, statement_list=statement_list@entry=true) at ../src/compiler/glsl/ir_hv_accept.cpp:55
#3  0x00007fffecf025f5 in do_variable_replacement (instructions=0x7fffffffd1d0, orig=0xb14b060, repl=0xb57d1c0) at ../src/compiler/glsl/opt_function_inlining.cpp:460
#4  ir_call::generate_inline (this=this@entry=0xb57d710, next_ir=next_ir@entry=0xb57d710) at ../src/compiler/glsl/opt_function_inlining.cpp:279
#5  0x00007fffecef32db in (anonymous namespace)::lower_builtins_visitor::visit_leave (this=0x7fffffffd370, ir=0xb57d710) at ../src/compiler/glsl/lower_builtins.cpp:61
#6  (anonymous namespace)::lower_builtins_visitor::visit_leave (this=0x7fffffffd370, ir=0xb57d710) at ../src/compiler/glsl/lower_builtins.cpp:53
#7  0x00007fffecee5bcd in visit_list_elements (v=v@entry=0x7fffffffd370, l=l@entry=0xb57c9b0, statement_list=statement_list@entry=true) at ../src/compiler/glsl/ir_hv_accept.cpp:55
#8  0x00007fffecee5d47 in ir_function_signature::accept (this=0xb57c960, v=0x7fffffffd370) at ../src/compiler/glsl/ir_hv_accept.cpp:115
#9  0x00007fffecee5bcd in visit_list_elements (v=v@entry=0x7fffffffd370, l=l@entry=0xb571b38, statement_list=statement_list@entry=false) at ../src/compiler/glsl/ir_hv_accept.cpp:55
#10 0x00007fffecee5dbe in ir_function::accept (this=0xb571b10, v=0x7fffffffd370) at ../src/compiler/glsl/ir_hv_accept.cpp:127
#11 0x00007fffecee5bcd in visit_list_elements (v=v@entry=0x7fffffffd370, l=l@entry=0xb56c770, statement_list=statement_list@entry=true) at ../src/compiler/glsl/ir_hv_accept.cpp:55
#12 0x00007fffecef3331 in lower_builtins (instructions=0xb56c770) at ../src/compiler/glsl/lower_builtins.cpp:48
#13 0x00007fffecec712b in _mesa_glsl_compile_shader (ctx=ctx@entry=0xadc76b0, shader=shader@entry=0xab66c90, dump_ast=dump_ast@entry=false, dump_hir=dump_hir@entry=false, force_recompile=force_recompile@entry=false)
    at ../src/compiler/glsl/glsl_parser_extras.cpp:2411
#14 0x00007fffecde81f7 in _mesa_compile_shader (ctx=0xadc76b0, sh=0xab66c90) at ../src/mesa/main/shaderapi.c:1234

I'm working on a fix and a test for this issue. Thanks for the report.

UPDATE: I was sent this and it works. Also, it is not localized to samplerCube , it also affects sampler2D and sampler2DArry. Probably all of them but these are the only ones I am using.

Timothy Arceri commented on a discussion:

If you want to avoid the current issue in mesa you should be able to change you code from:

FragColor = texture( samplerCube( reflection_map_bindless_texture ) , R );

to

sampleCube s = samplerCube( reflection_map_bindless_texture )
FragColor = texture( s , R );