Showing results for 
Search instead for 
Did you mean: 

OpenGL & Vulkan

Adept II

OpenGL Bug Generating Mipmap after getting TextureHandle causes sampling issues

I have a RX 5700 XT running newest driver (24.1.1).

Bug Description:

* Create a valid 2D Texture with compressed internal format

* Upload some pixels

* Generate a bindless texture handle

* Generate a mipmap for the texture

* Now in the shader, sampling the texture at every other LOD than 0 always returns black

I've implemented a minimal example to reproduce the issue. By default it shows some colors, but when the variable shouldReproduceBug is set to true (compressed format is picked), the screen is black.

I dont get this behaviour on an other nvidia gpu.

6 Replies

Can you provide full code source with all dependencies that can be compiled?


I can reproduce the issue. I will work on this.


According to spec, it is not allowed to change the texture storage after the handle is created. You cannot generate mipmap after you got a bindless texture handle.


(4) Can texture or sampler objects be modified while they are used by a texture or image handle?
RESOLVED: No. If such changes were permitted, each modification to the texture object would require potential synchronization with one or more texture/image handles extracted from the texture. This seems like a lot of bookkeeping with little benefit. One exception to this rule is that individual texels of such texture objects may still be updated with APIs such as TexSubImage* and by rendering to a framebuffer object to which the texture is attached.


I am aware of this part of the Bindless Textures spec. In its simplified form how I understand it is that: You can't change the textures state or size, but you can still update its content, after a handle was generated.

In my provided code the textures storage including all mip levels is allocated using the glTextureStorage2D function before getting the texture handle so that is fine.

glGenerateTextureMipmap is called after the handle is retrieved, but surely computing the mipmap only requires updating a textures content? - And thus should also be allowed.

In fact the driver actually seems to be computing a mipmap. I can readback the textures lower levels using glGetTextureSubImage and get back sensible values. So somewhere in memory there is a mipmap, which is properly filled. Its just that when it get sampled in the shader 0 is returned.



Right. Confirmed a driver bug. It will be fixed in future driver release.