[Mesa-dev] [PATCH 0/6] Some glapi clean-up releated to GLES

Brian Paul brianp at vmware.com
Wed Apr 2 06:55:04 PDT 2014


On 04/02/2014 06:21 AM, Jose Fonseca wrote:
> ----- Original Message -----
>> Tomorrow or Friday I'm going to send out the last of the
>> GL_ARB_separate_shader_objects patches.  Shortly after that, I will send
>> out patches to enable GL_EXT_separate_shader_objects on GLES.  This EXT
>> is the GLES subset of the ARB extension.
>>
>> In preparing for this new extension, I noticed the old problem that any
>> extension function that aliases a core function (whether it is core in
>> GLES or desktop GL) isn't hidden.  This series should fix that.
>>
>> Longer term, I'd like to change the generation of libGL*.  Right now all
>> the information describing the interfaces and the information selecting
>> the exposed interfaces in combined in a single XML database.  As patch 4
>> shows, that makes it impossible to have a single function that is
>> exposed in one API but hidden in another.  I'd like to pull all the
>> "offset", "static_dispatch", "glx_ignore", and "exec" information out
>> into separate files.
>>
>> This will mean that adding a new extension will require changes to
>> multiple files.  The usual XML bits will need to be added.  Entries will
>> need to be add to per-libGL* files, an "exec" file, and an "offsets".
>> We can probably get rid of the offsets file since no functions will ever
>> be added that have static offsets.
>
> ABI details like symbol visibility can vary not only per API but also per platform, so having these ABI details seperate from the prototypes (which are cross-platform and cross-API) sounds a good idea to me.
>
> On the topic of glapi cleanup, I noticed that a lot of glapi code ends up mixing scripted C code generation with C pre-processor macros. I'm sure there are historic reasons for it but this combination obfuscates the code. It would be better to use only one of the techniques; or more realistically, drop the macros and rely on code generation exclusively.  It would be much easier for humans to reason about the generated code then.

Definitely.  When I did the first version of the dispatch code in late 
'99 I hand-wrote the glapitable.h and glapitemp.h files.  When the 
python code generators came around (I _think_ I did the first version of 
that too), we (or I) should have immediately dropped the glapitemp.h 
file and just generated the .c files that were #including glapitemp.h 
directly.

I've been wanting to make that change for years but have never gotten 
around to it.

I'm in favor of anything that simplifies the dispatch code!

-Brian




More information about the mesa-dev mailing list