2010/5/7 Kristian Høgsberg <k...@bitplanet.net>: > 2010/5/7 Jakob Bornecrantz <wallbra...@gmail.com>: >> 2010/5/7 Kristian Høgsberg <k...@bitplanet.net>: >>> 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? >> >> I think there is some miss understanding here. >> >> My plan is to make have libEGL expose _libegl_dispatch* functions ala >> libGL and have the drivers use that in order to expose the EGL API. >> What would be a port of libEGL would be the dispatcher plus a very >> small platform specific loader. The rest of the src/egl/main code >> would be linked statically into the driver, in the case you care about >> into the egl_dri2.so driver. So its the EGL API I have made into xml >> files, sorry for any confusion caused. > > No I understand that. We currently have an interface between libEGL > and the EGL driver it loads. You're proposing to move that interface > up the stack to just below the EGL entry points. It's still going to > be a custom shared library interface and we're still stuck with one > .so (libEGL) dlopening another (EGL driver), which then dlopens a > third .so (DRI driver or gallium driver).
On a unrelated note if the distro choice to ship (or user choice to install) a gallium egl driver libEGL would load it directly without going via the egl_dri2.so loader. > > But you still didn't answer my question: what problem does this solve? Pretty much for all the same reasons we have a libGL dispatcher. Given that if we where to roll egl_dri2.so into the libEGL library the API exported by libEGL would be the dri interface we would not need one. But I like to keep the ability to load native (for lack of a better word) EGL drivers. Cheers Jakob. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
