Bug 90325 - No static entry point for glQueryCounter and other entry points in ARB_timer_query
Summary: No static entry point for glQueryCounter and other entry points in ARB_timer_...
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
Depends on:
Reported: 2015-05-05 20:36 UTC by nmcveity
Modified: 2015-05-05 22:10 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Simple program that demonstrates problem (271 bytes, text/plain)
2015-05-05 20:37 UTC, nmcveity
glxinfo output (19.30 KB, text/plain)
2015-05-05 20:37 UTC, nmcveity
Possible fix for the problem (1.14 KB, patch)
2015-05-05 20:45 UTC, nmcveity
Details | Splinter Review

Description nmcveity 2015-05-05 20:36:17 UTC
ARB_timer_query is part of OpenGL 3.3 but there does not appear to be static entry points for the new functions (glQueryCounter, glGetQueryObjectui64v, etc..)

Consider this simplified example:

#include <GL/gl.h>
#include <GL/glext.h>

int main(int nargs, char** args) {
  // From ARB_timer_query but should be core in 3.3
  glQueryCounter(GL_TIMESTAMP, 123);
  // From ARB_sampler_objects, also core in 3.3
  GLuint name;
  glGenSamplers(1, &name);
  return 0;

Attempting to link this:

nick@the-citadel:~/Projects/mesatest$ g++ query_counter.c -lGL -DGL_GLEXT_PROTOTYPES
/tmp/cczJxQBg.o: In function `main':
query_counter.c:(.text+0x29): undefined reference to `glQueryCounter'
collect2: error: ld returned 1 exit status

This is on ubuntu 10.14 (utopic). The mesa-dev package installed is the latest from xorg edgers:

amd64/utopic 10.6.0~git20150423.125574d1-0ubuntu0ricotz~utopic

I *ASSUME* this means it was built from the hash 125574d1effcb3e3eda93f2b2975bc6cc606df3e.
Comment 1 nmcveity 2015-05-05 20:37:06 UTC
Created attachment 115555 [details]
Simple program that demonstrates problem
Comment 2 nmcveity 2015-05-05 20:37:28 UTC
Created attachment 115556 [details]
glxinfo output
Comment 3 nmcveity 2015-05-05 20:45:17 UTC
Created attachment 115558 [details] [review]
Possible fix for the problem
Comment 4 nmcveity 2015-05-05 20:49:14 UTC
Looking at gl_API.xml, it appears to me that static_dispatch="false" should have been removed when the 3.3 support was added. If I remove static_dispatch from the functions in the ARB_timer_query category, then build, the generated shared object contains the missing entry points:

nick@the-citadel:~/Projects/mesa$ nm -D build/linux-x86_64-debug/mesa/drivers/x11/libGL.so | grep glQueryCounter
00000000000a0990 T glQueryCounter
Comment 5 Emil Velikov 2015-05-05 21:16:38 UTC
This might come a bit harsh, but what makes you think that libGL should provide static entry points for the said symbols ? Iirc EGL 1.4 had some strange thing where, core profile functions should be made available statically.

Does OpenGL 3.3 has a similar text somewhere ?

From a quick look at the spec, I don't see any mention that one should provide a static symbol, plus it is a extension after all :)
Comment 6 nmcveity 2015-05-05 21:50:36 UTC
QueryCounters was an extension but it was added to the core profile in 3.3, you can see it right there in section 5.1 (https://www.opengl.org/registry/doc/glspec33.core.20100311.withchanges.pdf).
Comment 7 Ian Romanick 2015-05-05 21:58:41 UTC
libGL is only supposed to export the symbols that are part of the Linux OpenGL ABI.  That is OpenGL 1.2 + GL_ARB_multitexture.  To maintain cross-distro / cross-vendor / cross-version compatibility, you must use glXGetProcAddress or glXGetProcAddressARB to access any other symbols.
Comment 8 Ian Romanick 2015-05-05 22:03:01 UTC
BTW... you should checkout libGLEW or libepoxy.
Comment 9 nmcveity 2015-05-05 22:10:09 UTC
Ah thanks. I got confused because some functions new to 3.3 ARE exported. But after reading the Linux OpenGL ABI document, yes, that is not something to be relied upon.

I tried GLEW but it doesn't support core profiles, will try epoxy.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.