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

[Kristian Høgsberg]

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?

Kristian