[PATCH 19/37] glx: Attempting to hide the GL stubs just makes the compiler angry

Chad Versace chad.versace at linux.intel.com
Mon Nov 18 13:54:24 PST 2013


On 11/18/2013 01:38 PM, Ian Romanick wrote:
> On 11/17/2013 12:01 AM, Keith Packard wrote:
>> Adding _X_HIDDEN doesn't actually maange to hide these functions as
>> the compiler refuses to change the visibility from what was declared
>> in gl.h
>>
>> Signed-off-by: Keith Packard <keithp at keithp.com>
>> ---
>>   glx/glxstubs.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/glx/glxstubs.c b/glx/glxstubs.c
>> index 69bc004..99f1cba 100644
>> --- a/glx/glxstubs.c
>> +++ b/glx/glxstubs.c
>> @@ -34,7 +34,7 @@
>>   #include "glxserver.h"
>>
>>   #define thunk(name, type, call_args, ...) \
>> -    _X_HIDDEN void name(__VA_ARGS__) { \
>> +    GLAPI void APIENTRY name(__VA_ARGS__) { \
>>   	static type proc; \
>>   	if (!proc) proc = __glGetProcAddress(#name); \
>>   	proc call_args; \
>>
>
> Yeah.... this can't work reliably and is generally yucky.  I'm curious
> why Adam didn't just use the GLEW trick of having a #define glFoo that
> calls through a function pointer _glewFoo.  I think Waffle does
> something similar... but is much more clever than GLEW by avoiding the
> need for a glewInit function.

On 11/18/2013 01:38 PM, Ian Romanick wrote:
 > On 11/17/2013 12:01 AM, Keith Packard wrote:
 >> Adding _X_HIDDEN doesn't actually maange to hide these functions as
 >> the compiler refuses to change the visibility from what was declared
 >> in gl.h
 >>
 >> Signed-off-by: Keith Packard <keithp at keithp.com>
 >> ---
 >>  glx/glxstubs.c | 2 +-
 >>  1 file changed, 1 insertion(+), 1 deletion(-)
 >>
 >> diff --git a/glx/glxstubs.c b/glx/glxstubs.c
 >> index 69bc004..99f1cba 100644
 >> --- a/glx/glxstubs.c
 >> +++ b/glx/glxstubs.c
 >> @@ -34,7 +34,7 @@
 >>  #include "glxserver.h"
 >>
 >>  #define thunk(name, type, call_args, ...) \
 >> -    _X_HIDDEN void name(__VA_ARGS__) { \
 >> +    GLAPI void APIENTRY name(__VA_ARGS__) { \
 >>  	static type proc; \
 >>  	if (!proc) proc = __glGetProcAddress(#name); \
 >>  	proc call_args; \
 >>
 >
 > Yeah.... this can't work reliably and is generally yucky.  I'm curious
 > why Adam didn't just use the GLEW trick of having a #define glFoo that
 > calls through a function pointer _glewFoo.  I think Waffle does
 > something similar... but is m
 > uch more clever than GLEW by avoiding the
 > need for a glewInit function.


Ian's thinking of some code in Piglit. In Piglit, the thunk is hit only on the
first call to glFoo. All subsequent calls to glFoo go to the *real* glFoo and
have no thunk overhead.

Here's the Piglit code for glClear.

glClear is #defined to piglit_dispatch_glClear, which is a function pointer.
At process startup, that pointer points to a thunk that resets itself to point
to the *real* glClear returned by glXGetProcAddress("glFoo"). Therefore, the thunk
gets exercised only the first call to glClear.


// ----------------------------------------------
// file: generated_dispatch. h
// ----------------------------------------------

/* glClear (GL 1.0) */
/* glClear (GLES 2.0) */
extern PFNGLCLEARPROC piglit_dispatch_glClear;
#define glClear piglit_dispatch_glClear


// ----------------------------------------------
// file: generated_dispatch. c
// ----------------------------------------------

/* glClear (GL 1.0) */
/* glClear (GLES 2.0) */
static piglit_dispatch_function_ptr resolve_glClear()
{
         if (dispatch_api == PIGLIT_DISPATCH_GL)
                 piglit_dispatch_glClear = (PFNGLCLEARPROC) get_core_proc("glClear", 10);
         else if (dispatch_api == PIGLIT_DISPATCH_ES2)
                 piglit_dispatch_glClear = (PFNGLCLEARPROC) get_core_proc("glClear", 20);
         else
                 unsupported("Clear");
         return (piglit_dispatch_function_ptr) piglit_dispatch_glClear;
}
static void APIENTRY stub_glClear(GLbitfield mask)
{
         check_initialized();
         resolve_glClear();
         piglit_dispatch_glClear(mask);
}
PFNGLCLEARPROC piglit_dispatch_glClear = stub_glClear;






More information about the xorg-devel mailing list