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

[Chia-I Wu]

2010/4/29 Kristian Høgsberg <krh at bitplanet.net>:
> 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?
Yes, I think so.
>
>> - 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?
Yes.  The issue is that __DRIscreenRec::api_mask does not reflect the real APIs
supported.  It always has __DRI_API_OPENGL set if a driver does not override
it.  But this is probably minor.
>> - 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.
I am not a fan of having generated sources in git, but I don't have a strong
opinion here.  Especially when I do not have a better solution :)

Ideally, I would like to have python a requirement for developers.  And those
sources are generated when making a release tarball so that python is not a
requirement for users.
>> - 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?
The branch has a dispatcher generator called mapi (multiple-api, in contrary to
gl-api).  It is simple and easy to set up.  I use it to create an OpenVG
dispatcher (see the commit "mapi: Add vgapi.").

glapi dispatcher consists of

 1) current dispatch/context management
 2) a C version of the dispatcher
 3) several assembly versions of the dispatcher

In the branch, I do not use mapi to replace glapi dispatcher yet.  Instead,
only 1) of glapi dispatcher is converted to use mapi.  The plan is to have the
branch reviewed and merged, and then convert 2) to use mapi.  And once mapi has
every assembly dispatcher currently in glapi, I can then convert 3) to use
mapi.

I am out of town next week.  I would like to post the branch for review once I
get back.

-- 
olv at LunarG.com