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

Cheers Jakob.