GlTextureParameteriEXT being called from Core profile
-
EDIT: Ignore this, the problem was me - everything works as it should do (see below)
If I
- Create a core 3.3 OpenGL context
- Grab a core 3.3 functions object via versionFunctions()
- Call glTexParameteri() on that object
What actually seems to happen is a call to glTextureParameteriEXT().
This in turn breaks tracing with VOGL as it's not in their whitelist.
Tried manually requesting the function via
@QOpenGLContext::currentContext()->getProcAddress("glTexParameteri"));@
then casting the returned pointer to the appropriate type and using it directly, but it seems to still wind up with the EXT version.Is it possible to restrict use of extensions even if they are available?
-
Hi and welcome to devnet,
Since this might dig a bit deeper in the OpenGL stack implementation, I'd recommend asking this question on the interest mailing list, you'll find there Qt's developers/maintainers (this forum is more user oriented)
-
@
auto a = QOpenGLContext::currentContext()->getProcAddress("glTexParameteri");
auto b = QOpenGLContext::currentContext()->getProcAddress("glTextureParameteriEXT");
qDebug() << a << b;
@
This returns different addresses for me (Win 8.1, NVidia 340.82). Doesn't sound like Qt problem if it's down to function pointers. Might be a driver issue. AMD did some pretty weird hacks in their drivers back in the time. What OS/graphics card are you on? -
So it turns out I'm a total idiot, and shouldn't post things last thing on a Friday afternoon.
I was getting bits of my trace confused and thought some calls eminating from a QOpenGLTexture object were the ones I was manually calling myself.
Both calling glTexParameteri() via the function pointer returned from getProcAddress() and calling glTexParameteri() directly via the function object work exactly as you would expect them to, QOpenGLTexture is just doing the right thing by using direct state access when it can (hence glTextureParameteriEXT)
Sorry everyone!
