2010/5/7 Jakob Bornecrantz <wallbra...@gmail.com>: > 2010/5/7 Kristian Høgsberg <k...@bitplanet.net>: >> On Wed, May 5, 2010 at 10:43 AM, Jakob Bornecrantz <wallbra...@gmail.com> >> wrote: >>> On Wed, May 5, 2010 at 3:34 PM, Chia-I Wu <olva...@gmail.com> wrote: >>>> On Wed, May 5, 2010 at 6:04 PM, Keith Whitwell <kei...@vmware.com> wrote: >>>>> On Tue, 2010-05-04 at 22:48 -0700, Chia-I Wu wrote: >>>>>> 2010/5/2 Chia-I Wu <olva...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev