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

[Kristian Høgsberg]

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)?

> 2. I think I'd like the code related to compressed/paletted textures to live
> in a separate source file.  The teximage.c file is pretty big already.  This
> could be done later though - no big deal.

Yup, I'll split that out.

> You can merge this to mesa/master whenever you want, as far as I'm
> concerned.

Excellent, thanks.  There's a bunch of things we can do on top of
this, such as exposing the GLES2 functionality as OpenGL extensions,
reducing the size of a GLES2-only driver, reduce the GLES2 dispatch
tables etc, but I think this branch is a good first step.

Kristian