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

[Mark Mueller]

Would it work to put a dummy value into the enum to assure you get the
size you want?

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
      __DRI_API_MAX_VALUE = 0xFFFF
};


Mark


2010/4/28 Kristian Høgsberg <krh at bitplanet.net>:
> 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>