[Mesa-dev] Merging GLES1/2 to mesa/main

[Kristian Høgsberg]

2010/4/28 Jakob Bornecrantz <jakob at vmware.com>:
> On 2010-04-28 17.32, Kristian Høgsberg wrote:
>>
>> 2010/4/28 Brian Paul<brianp at vmware.com>:
>>>
>>> Kristian Høgsberg wrote:
>>>>
>>>> 2010/4/27 Kristian Høgsberg<krh at bitplanet.net>:
>>>> [ I hit send to early there... ]
>>>>>
>>>>> review the patches, or at least just some of them.  The overall
>>>>> approach is
>>>>
>>>>  1. Add a API tag to GLcontext so we key off of that.
>>>>  2. Use API-aware constructor where we create GLES1/2 contexts
>>>> (currently only ES1/2 state trackers)
>>>>  3. Move ES functionality from src/mesa/es into src/mesa/main in a
>>>> number of steps (this is the bulk of the series).  To make this work
>>>> we have to change some of the tables and generated code so it can all
>>>> co-exists in the same .so file.
>>>>  4. Update the DRI interface to allow creating API specific contexts
>>>>  5. Use the new DRI interface in EGL/DRI2
>>>>  6. Build libGLES1/2 from the glapi files
>>>>
>>>> I'm hoping to merge the branch this week, but if somebody wants to
>>>> spend a little longer looking over the patches, let me know and I can
>>>> wait.
>>>
>>> Looks good, Kristian.  Just minor things...
>>>
>>> 1. Can the __DRI_API_* values be made into a real enum (as you did with
>>> gl_api in core Mesa)?  And replace the 'int api' parameter with the enum
>>> type.
>>
>> I didn't make it an enum because I'm paranoid about using enums in
>> APIs where we're concerned about preserving binary compatibility.  The
>> way it's used in the DRI interface, it's only passed to a function and
>> most compilers will probably promote it to an int.  Even so, can we
>> keep it as an int in the DRI interface, if I convert it to the mesa
>> enum internally as soon as we get into the DRI driver (that is, in
>> dri2CreateNewContextForAPI)?
>
> You want the debuggers to pickup on the value in the backtrace so you don't
> have to go snooping around with prints to get the textual value.
>
> For the paranoid, you can always specify the value for all enums. As well
> for all the entries define a define for code that expects them to be
> defines, like so:
>
> enum __dri_api_enum {
>        __DRI_API_OPENGL = 0,
> #define __DRI_API_OPENGL __DRI_API_OPENGL
>        __DRI_API_GLES1 = 1,
> #define __DRI_API_GLES1 __DRI_API_GLES1
>        __DRI_API_GLES2 = 2,
> #define __DRI_API_GLES2 __DRI_API_GLES2
> };

It's not about the values that get assigned to the enum members, it's
about the size of the enum.  The only requirement on the size is that
it's big enough to hold the members of the enum, so
sizeof(__dri_api_enum) could be 1, 2 or 4, depending on your compiler.
 You don't want that in your ABI.

Kristian