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

[Kristian Høgsberg]

2010/4/28 Chia-I Wu <olvaffe at gmail.com>:
> 2010/4/28 Kristian Høgsberg <krh at bitplanet.net>:
>> 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.
> Nice work.  I will give my feedbacks based on a quick look at the branch.
> Correct me if I am wrong.
>
> - GL_TEXTURE_GEN_STR_OES is not handled in _mesa_IsEnabled in
>  989f4414378a6cbd2ac920d955d162ba58a06bc0.

Oops, you're right.  Fixed.

> - Links to intel_extensions_es2.c are missing in i915/ and i965/

Oh yea, I forgot to add those, I had them in my checkout. Fixed.

> - in src/mesa/es/Makefile, FEATURE_GL and FEATURE_ES2 should be undefined for
>  libes1gallium.a; FEATURE_GL and FEATURE_ES1 should be undefined for
>  libes2gallium.a.

I moved the flags to API_DEFINES and only add that to CFLAGS when
we're compiling in src/mesa and src/mesa/drivers/dri.  That should
restore the flags in src/mesa/es, right?

> - In st_create_context, API_OPENGL context should be preferred.  Otherwise,
>  gallium gives broken DRI drivers (claim OPENGL, but is GLES) when
>  --enable-gles[12] is given.

I'm not sure what you mean here.  Are you saying that #if FEATURE_GL
should be the first case in the #if-sequence in st_context.c?

> - The practices for core mesa and es overlay about generated sources are
>  different.  Core mesa uses pre-generated sources.  Either api_exec_es?.c or
>  get_es?.c should be pre-generated, or get.c should be generated on the fly.

Yeah, I noticed... I don't have a good answer.  I guess core mesa
doesn't generate on the fly because we don't want to require python as
part of the build process(?) and also so that when we distribute mesa,
all the files are in the tarball.  I don't know if we can move to just
generate everything, but we can always just generate the es1 and es2
api files and commit them.  That would solve the ordering issue you
mention below too.

> - es glapi headers should be generated before compiling core mesa with
>  --enable-gles[12].  If it is too much trouble, you may leave it for now.  I
>  am cleaning up glapi[*], and it should be easier to do after the clean up.

That sounds good to me.  I did want to move the es[12] glapi
directories somewhere else, was considering src/mesa/es1api.

> [*] I am extracting a good portion of glapi to make it reusable in gallium (for
>    OpenVG).  It is done, but I haven't had the time to post it to the list for
>    review.  It is available at
>
>      http://cgit.freedesktop.org/~olv/mesa/log/?h=mapi

Interesting.  What's your plan for the big dispatch table for VG code?

Kristian