OpenGL & Vulkan

[anyoldname3]

I'm (indirectly via Qt's QOpenGLTexture) using EXT_direct_state_access to upload textures to the GPU. With the EXT version of DSA, I should be able to call glGenTextures to get a texture name, call glTextureStorage2DEXT to initialise it (without having to bind it first) and allocate immutable storage, and then call glCompressedTextureSubImage2DEXT with the cubemap face as the target parameter. However, even though glTextureSubImage2DEXT works just fine when used like this, the compressed version gives a GL_INVALID_OPERATION error. This doesn't change if I bind the texture first, so I'm assuming it's down to someone confusing it with the ARB/Core version of DSA, which requires that the 3D version of the function is used, and cubemap faces to be treated as array layers. The same data works fine if I hack around QOpenGL's mechanisms and use the non-DSA version, glCompressedTexSubImage2D, so I know it's not a data error.

Apparently, this is a regression introduced between 18.9.3 and 19.4.1 (according to someone else who worked around the issue without reporting it), although I've not tested that myself. I've had the issue on my on Vega 56 with 19.8.1, and a user with an RX 580 (but an unknown driver version) reported the same problem.

I have APITraces for various behaviours, so can upload those on request, which I imagine might be more useful than an example application that requires Qt, and that would be easier for me as I already have them (whereas a minimal example would involve starting from scratch, as the application I'm working on has a lot of dependencies).

[anyoldname3]

Now the post has been approved, can it be moved to the OpenGL and Vulkan subforum? I imagine it's not going to be seen by the right people if it's left in Newcomers Start Here.

[dipak]

I've whitelisted you and moved this post to the OpenGL forum.

Thanks.

[dorisyan]

Hi anyoldname3‌, Thanks for your report, could you please provide a minimal code that can reproduce this problem?

[anyoldname3]

How minimal is minimal? It'll take some time for me to set something up with the bare minimum of dependencies.

In the meantime, here's a fairly minimal APITrace. The important calls are in this screenshot:

[anyoldname3]

Here's a minimal example using only GLFW and GLAD. The important stuff is all in main.cpp, with texture.cpp and texture.hpp just containing the texture.

[anyoldname3]

One thing I did notice is that the issue doesn't occur with a 3.0 or later context, whether or not it's in core mode or compatibility mode. It's only 2.1 and below that exhibit the issue, even though the extension is exposed with all versions I tried.

[dorisyan]

If this issue disapeared from 3.0v and later, maybe it means this bug has been fixed in the latest version.

I will suggest you to use the latest version context.

[anyoldname3]

As stated in the original post, this is a regression compared with drivers from a year ago (although I don't know which specific update introduced the problem). It's still there in 19.10.1, too.

If AMD's official stance is that DSA is only supported with newer OpenGL contexts, the driver shouldn't advertise EXT_direct_state_access compatibility when contexts are created with old versions. Applications can predicate DSA usage on whether the extension is there, but bumping the minimum required GL version just because one vendor's drivers advertise an unsupported extension is a little extreme.

[dorisyan]

Hi anyoldname3‌, I have got it, you can use higher version to avoid this bug, we will take a look into this regression. Thanks!

[dorisyan]

Hi anyoldname3‌, Thanks for your effort, and I will try to reproduce it soon.