Getting INVALID_OPERATION on first call to extension

[wookie]

Hi,

While adding bindless textures support my program I run into an error when calling glGetTextureHandleARB.

The gist of what I’m doing is

glGenTextures(1, &textureHandle);
glBindTexture(GL_TEXTURE_2D, textureHandle);
glTexImage2D(GL_TEXTURE_2D, MipMapLevel, DataFormat, TextureSize.x, TextureSize.y, 0, PixelFormat, DataType, TextureData);
glGenerateMipmap(GL_TEXTURE_2D);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);        glBindTexture(GL_TEXTURE_2D, 0);

glGetTextureHandleARB(textureHandle);

I’m using GLAD to load the function’s addresses and I’ve checked the GL_ARB_bindless_texture extension when generating GLAD. The video card itself supports the extension as well.

What is happening is that I’m getting the INVALID_OPERATION (1282) error on the very first call to glGetTextureHandleARB.
Subsequent calls return no error, so it looks like the extension is not loaded on the first call and the function address gets patched after it (?).

I’ve even replaced GLEW which I’ve used before with GLAD, thinking there is something wrong with GLEW’s extension loading.

Another thing that makes me think it’s somethig related to the address patching is the fact that when I try to run my program via RenderDoc, the RenderDoc crashes with Data Execution Prevention error, as if it was trying to execute some funky address.

Does anyone have an idea what might be wrong?

[wookie]

What’s even more surprising is this result

Result: 1281 2560
Result: 0 2560
Result: 0 2561
Result: 0 2561
Result: 0 2562
Result: 0 2562
Result: 0 2563
Result: 0 2563

The code that generated it loads 4 different textures using the code I posted above and then calls glGetTextureHandleARB two times for each texture.
The first number in the message is the error code, the second is the bindless handle.

I’ve put a fence and waited for it before glGetTextureHandleARB command but without success. The output is still the same.

(what I dead in a meanwhile is fixed a bug that caused the textures to be loaded in a different OpenGL context, this made the error code go from 1282 to 1281. The seconds context is here because of Imgui that I use for UI)

[wookie]

That’s funny. When running the program with RenderDoc the GL_ARB_bindless_texture extension is reported as unsupported.

This would explain the crash when running with RenderDoc.

The error code that is generated on the very first call to glGetTextureHandleARB is some error set by a different function call that I called ealier…
Now I think like an idiot.

I’ll leave this thread though, in case anyone stumbles upon the RenderDoc thing.

In this thread people report the same error Support of incompatible OpenGL functions. · Issue #850 · baldurk/renderdoc · GitHub

[Dark_Photon]

@wookie

When running the program with RenderDoc the GL_ARB_bindless_texture extension is reported as unsupported.

Ok, so bindless texture is really working fine (except in RenderDoc) and you were chasing a stale GL error thrown by some code prior to your bindless texture calls?

If so, you might consider using this to track GL errors instead:

• OpenGL Error # Catching errors (the easy way)

With this, when a GL error occurs, your app is immediately kicked with a callback to tell you that an error condition was thrown (and to provide a useful message to display).

Also, on NVIDIA OpenGL drivers, this callback is often dispatched from the exact GL call that triggered the GL error. Not sure about other drivers. So tripping a breakpoint and/or dumping a callstack to the log inside of this callback will point you exactly to where this GL error occurred.

Once you’re using this, you’ll probably find that can just delete all the old glGetError() calls and any related macros from your code, and forget about ever calling this function again.