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

[Jakob Bornecrantz]

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.

Cheers Jakob.