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

[Jakob Bornecrantz]

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>:
>>> 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).

On a unrelated note if the distro choice to ship (or user choice to
install) a gallium egl driver libEGL would load it directly without
going via the egl_dri2.so loader.

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

Pretty much for all the same reasons we have a libGL dispatcher. Given
that if we where to roll egl_dri2.so into the libEGL library the API
exported by libEGL would be the dri interface we would not need one.
But I like to keep the ability to load native (for lack of a better
word) EGL drivers.

Cheers Jakob.