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

Cheers Jakob.