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

Kristian