[Mesa-dev] [RFC] mapi: a generic dispatcher to be used by OpenVG (and OpenGL)

[Kristian Høgsberg]

2010/5/7 Jakob Bornecrantz <wallbraker at gmail.com>:
> 2010/5/7 Kristian Høgsberg <krh at bitplanet.net>:
>> 2010/5/7 Jakob Bornecrantz <wallbraker at gmail.com>:
>>> 2010/5/7 Kristian Høgsberg <krh at bitplanet.net>:
>>>> On Wed, May 5, 2010 at 10:43 AM, Jakob Bornecrantz <wallbraker at gmail.com> wrote:
>>>>> On Wed, May 5, 2010 at 3:34 PM, Chia-I Wu <olvaffe at gmail.com> wrote:
>>>>>> On Wed, May 5, 2010 at 6:04 PM, Keith Whitwell <keithw at vmware.com> wrote:
>>>>>>> On Tue, 2010-05-04 at 22:48 -0700, Chia-I Wu wrote:
>>>>>>>> 2010/5/2 Chia-I Wu <olvaffe at gmail.com>:
>>>>>>>> > I've been working on and off for a while on a dispatcher builder called mapi
>>>>>>>> > (multiple-api, in contrary to gl-api).  The code is available at
>>>>>>>> >
>>>>>>>> >  http://cgit.freedesktop.org/~olv/mesa/log/?h=mapi
>>>>>>>> >
>>>>>>>> > The motivation is to build a dispatcher for OpenVG.  I will give an overview
>>>>>>>> > for mapi in this mail, and see if it could be merged and how.
>>>>>>>> I've rebased the branch onto current master and pushed it here
>>>>>>>>
>>>>>>>>   http://cgit.freedesktop.org/~olv/mesa/log/?h=mapi-rebased
>>>>>>>>
>>>>>>>> mapi was discussed in my last mail.  Of the 8 commits, the first three cleans
>>>>>>>> up glapi.  They were not discussed yet.
>>>>>>>>
>>>>>>>> So, briefly,
>>>>>>>>
>>>>>>>>   glapi: Move assembly dispatchers back into glapi/.
>>>>>>>>    - move <ARCH>/glapi-<ARCH>.S to glapi/glapi-<ARCH>.S in preparation for the
>>>>>>>>      next commit
>>>>>>>>
>>>>>>>>   glapi: Move to src/mapi/.
>>>>>>>>    - move glapi (core mesa and es overlay) to src/mapi/{glapi,es1api,es2api}
>>>>>>>>    - update the Makefile rules to build and use the new directories
>>>>>>>>
>>>>>>>>   mapi: Add mapi and share the code with glapi.
>>>>>>>>    - add mapi utility functions that are actually glapi.c, glapi_execmem.c, and
>>>>>>>>      glthread.c, with dependency on core mesa removed.
>>>>>>>>    - update glapi to use mapi utility functions.
>>>>>>>>
>>>>>>>> The changes pave the way for the following 5 commits that add mapi and OpenVG
>>>>>>>> dispatcher.
>>>>>>>>
>>>>>>>> The branch is compile tested with linux-debug, autoconf, and scons.  I've also
>>>>>>>> tested it with autoconf on x86 and x86-64.  I would like to merge it late
>>>>>>>> Thursday (U.S. time), if there is no objection.
>>>>>>> This is looking pretty good to me.
>>>>>>> Is there now some additional work that can be done to restrict the
>>>>>>> visibility of the new vegaXyz() functions, or is that handled in some
>>>>>>> way I missed?
>>>>>> You meant in the final shared library?  They are hidden when
>>>>>> -fvisibility=hidden is given.  It is the default with autoconf.  It
>>>>>> doesn't seem to be the case with scons, but I think scons should be
>>>>>> fixed.  The option should be safe now that autoconf has it for several
>>>>>> months.
>>>>>>
>>>>>> Following the merge, I would like to move vegaXyz functions out of
>>>>>> libOpenVG.so and distribute them with EGL drivers.  Same to OpenGL ES.
>>>>>>  That should solve the issue that st/egl and client APIs disagree on
>>>>>> the  version of Gallium used.  It also allows st/egl to support OpenGL
>>>>>> with non-st/glx libGL.so.
>>>>>
>>>>> I have started work on a libEGL dispatcher I turned the EGL api into
>>>>> xml files and figured out how do deal some of the more trickier parts
>>>>> of the API.
>>>>
>>>> What are you trying to solve with this work?
>>>
>>> I think it is unwise to have a API between libEGL and the drivers be
>>> based on something that we offer no stability in, and IMHO shouldn't,
>>> just as we do with the mesa driver API. Thats the main reason anyways.
>>
>> How does defining the API in XML make it stable?
>
> I think there is some miss understanding here.
>
> My plan is to make have libEGL expose _libegl_dispatch* functions ala
> libGL and have the drivers use that in order to expose the EGL API.
> What would be a port of libEGL would be the dispatcher plus a very
> small platform specific loader. The rest of the src/egl/main code
> would be linked statically into the driver, in the case you care about
> into the egl_dri2.so driver. So its the EGL API I have made into xml
> files, sorry for any confusion caused.

No I understand that.  We currently have an interface between libEGL
and the EGL driver it loads.  You're proposing to move that interface
up the stack to just below the EGL entry points.  It's still going to
be a custom shared library interface and we're still stuck with one
.so (libEGL) dlopening another (EGL driver), which then dlopens a
third .so (DRI driver or gallium driver).

But you still didn't answer my question: what problem does this solve?

Kristian