cancel
Showing results for 
Search instead for 
Did you mean: 

OpenGL & Vulkan

stailgot
Adept II

Null pointer for glMemoryBarrierByRegion & crashes sampler2D from GL_ARB_bindless_texture

Hello,

I found two problems in newer driver 22.7.1 and 23.7.2. 

1) Program crashes when I call glMemoryBarrierByRegion. Exception said that I accessed to null pointer. I guess GLEW couldn't setup this function on this driver. glMemoryBarrier works fine.

2) I use extension GL_ARB_bindless_texture and my materials has some textures (like uvec2 handles) and I use them in shader like

 

color = texture2D(sampler2D(handle), st)

 

But during the draw-call, my program crashes with callstack. As I comment this line or replace sample2D(handle) on uniform texture - everything works fine.

 

> atio6axx.dll!00007fff5e189190() 
atio6axx.dll!00007fff5e18bbbf() 
atio6axx.dll!00007fff5ddbecb7()
atio6axx.dll!00007fff5e198a83() 
atio6axx.dll!00007fff5e198431()
atio6axx.dll!00007fff5d848750() 
atio6axx.dll!00007fff5d84716c() 
atio6axx.dll!00007fff5d82ab67() 
atio6axx.dll!00007fff5d52a2b2() 
atio6axx.dll!00007fff5d54abeb() 
atio6axx.dll!00007fff5d552ccd() 
atio6axx.dll!00007fff5d5f3d97() 
atio6axx.dll!00007fff5d53e9c6() 
atio6axx.dll!00007fff5d52b96c() 
atio6axx.dll!00007fff5d46e6ed() 
atio6axx.dll!00007fff5d46e1d9()
atio6axx.dll!00007fff5d3918c0() 
atio6axx.dll!00007fff5d2ea9d1() 
atio6axx.dll!00007fff5d1fd245() 
atio6axx.dll!00007fff5d20d861() 
atio6axx.dll!00007fff5d203123() 
atio6axx.dll!00007fff5d203ef0() 
atio6axx.dll!00007fff5d248b4f() 
atio6axx.dll!00007fff5d1debd9() 
atio6axx.dll!00007fff5d1c5d68() 
atio6axx.dll!00007fff5cef682f() 
atio6axx.dll!00007fff5eced956() 
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart() 

 

On NVidia GPUs and older driver versions works fine.

I wrote reproducer to show all these problems. 

There is my PC configuration

stailgot_0-1692959780160.png

Please check it.

 

 

 

0 Likes
1 Solution
dipak
Big Boss

>> 1) Program crashes when I call glMemoryBarrierByRegion. Exception said that I accessed to null pointer. I guess GLEW couldn't setup this function on this driver. glMemoryBarrier works fine.

The OpenGL team was able to reproduce the issue. It seems that the related extension is not currently exposed in the driver, hence the crash was observed. They will implement a fix for it.

Thanks.

View solution in original post

0 Likes
17 Replies
dipak
Big Boss

Hi @stailgot ,

Thanks for reporting the above issues and providing the reproducible example. I have created two internal tickets to track those issues. 

Thanks.

0 Likes
dipak
Big Boss

Hi @stailgot ,

>>2) I use extension GL_ARB_bindless_texture ...

Here is the OpenGL team's feedback on the 2nd issue:

It is an application issue, the bindless handle is not uploaded correctly, if we change the following API call

glUniform2uiv(handle_loc, 2, reinterpret_cast<GLuint*>(&handle));
to
glUniform2uiv(handle_loc, 1, reinterpret_cast<GLuint*>(&handle));

We can get the correct rendering result:

dipak_1-1693477893985.png
 

Thanks.

 

0 Likes

Hi @stailgot ,

Can you please confirm if the above suggestion resolves the 2nd issue?

Thanks.

0 Likes

Hello,

Actually, no. You're right, this reproducer doesn't show my problem, it's just my mistake.

The problem code is (it's in fragment shader, it's important)

 

 

 

void main()
{
    ...
    uvec2 handle = ...; //it's from SSBO, not uniform
    if (handle != uvec(0))
        fragColor = texture2D(sampler2D(handle), uv); // crash because calls sampler2D(uvec2(0))
    else ...
    ...
}

 

 

 

And I guess the crash reason is sampler2D(uvec2(0)), due to shader executes if-body anyway. But there is other way to crash, not program - driver crashes and GPU is not responding. I have to reboot my PC.

I solved it with dummy texture contains one pixel - vec4(0). Program still crash with the same callstack. I started to pass sampler2D instead of uvec2 in SSBO. And it's helped but not for long.

Program don't crash but there is a garbage in textures. If I just apply texture on geometry, I got this result. 

 

image.png

Next, I replace my SSBO with textures from fragment shader to vertex shader, there I take sampler2D from SSBO and pass it in Fragment shader via interface block or just in/out variables. The program didn't crash and texture was rendered. But there is a garbage in rendering result. It looks like this image and I can't reproduce it.

stailgot_0-1694079001610.png

 

So, I guess, truly reason of my crash - is garbage in fragment shader.. Otherwise I can't understand why SSBO's replacing is helped to me. Maybe you can suggest some ways how to reproduce it or how solve?

0 Likes

Also important thing - our rendering is  multipass and indirect. And there is the pass of culling (occlusion). It's just compute shader which got some SSBOs as input and write result in the other SSBOs (it's an intersecting set with input SSBOs). I noticed that texture's garbage is changed when I remove this occlusion pass. Maybe it has affect on textures or other SSBOs.

P.S. glMemoryBarrier is using and I guess it's correct

0 Likes

Hi @stailgot ,

Thanks for sharing your observation about the 2nd issue. I have informed the OpenGL team and shared your observation with them.

Thanks.

0 Likes

Thank you. Keep me informed)

I continue to investigate this problem and if I knew something, i'll let you know

Hi, @dipak .

I found reason for this

stailgot_0-1694407797394.png

We use framebuffer with multiple color attachments (like texture attachment). Before rendering we must clear all attachments. We do it with

 

 

glClearNamedFramebufferfv(dest_framebuffer, GL_COLOR, 0, std::data(color));
glClearNamedFramebufferfv(dest_framebuffer, GL_COLOR, 1, std::data(color));
glClearNamedFramebufferfv(dest_framebuffer, GL_COLOR, 2, std::data(color));
glClearNamedFramebufferfv(dest_framebuffer, GL_COLOR, 3, std::data(color));
glClearNamedFramebufferfv(dest_framebuffer, GL_COLOR, 4, std::data(color));

 

 

But framebuffer has also draw buffers - buffers marked to be drawn, and, by default, framebuffer has only one color attachment to be drawn. So other attachments don't become clear if you didn't call glDrawBuffers before. We use.

 

 

glNamedFramebufferDrawBuffers(dest_framebuffer, 4, {GL_COLOR_ATTACHMENT4, GL_COLOR_ATTACHMENT1, GL_COLOR_ATTACHMENT2, GL_COLOR_ATTACHMENT3});

 

Garbage solved when I add glDrawBuffers call before glClearBuffer, but problem with crash on sampler2D constructor still unknown.

 

 

0 Likes

Thanks for the above information. I will pass it on to the OpenGL team.

Thanks.

0 Likes

I managed to find out reason of my crash.

Our shaders are built from one vertex shader and some fragments shaders. I mean there is one main fragment shader and multiple additionals. They contains functions to calc color for light for example. It is reason for crash. If I built shader program only from one vertex and one fragment shader - everything works fine. 

I write a reproducer you can take (it's not include problem with framebuffer). I checked it on new driver 23.9.1 - it's repeated.

So here's two separate problems: crash due to shader program built from multiple source files and garbage in framebuffer due to glCleanBuffer doesn't clean not drawing buffers. Both are repeated on 23.9.1

0 Likes

Thanks for sharing the above observation. I have informed the OpenGL team.

Thanks. 

>> So here's two separate problems: crash due to shader program built from multiple source files and garbage in framebuffer due to glCleanBuffer doesn't clean not drawing buffers. Both are repeated on 23.9.1

Could you please share the reproducible example for the 2nd issue i.e. "garbage in framebuffer as glClearBuffer doesn't clear drawing buffers" ?

Thanks.

0 Likes

I have seen it in more detailed way. I can't reproduce garbage because, I guess, it's from several fragment shaders attached to program (problem 1 I described). I reproduce that glClearBuffer doesn't clear non draw buffers (which are not marked as draw with glDrawBuffers), but it seems it's fine behavior. So I guess main problem is problem 1.

Sorry for confused 

0 Likes

Thanks for the information. We have created a ticket for the 1st issue i.e. "crash due to shader program built from multiple source files". Will keep you posted on its progress.

Thanks.

Update:

Regarding the 1st issue i.e. "crash due to shader program built from multiple source files",  the OpenGL team was able to reproduce this issue. They are investigating it.

Thanks.

dipak
Big Boss

>> 1) Program crashes when I call glMemoryBarrierByRegion. Exception said that I accessed to null pointer. I guess GLEW couldn't setup this function on this driver. glMemoryBarrier works fine.

The OpenGL team was able to reproduce the issue. It seems that the related extension is not currently exposed in the driver, hence the crash was observed. They will implement a fix for it.

Thanks.

0 Likes
dipak
Big Boss

Hi @stailgot ,

1) Program crashes when I call glMemoryBarrierByRegion. Exception said that I accessed to null pointer. I guess GLEW couldn't setup this function on this driver. glMemoryBarrier works fine.

Could you please try the latest driver ( Adrenalin 23.10.1) and let us know if the above issue has been resolved?

Thanks.

0 Likes