2010/5/7 Jakob Bornecrantz <wallbra...@gmail.com>: ... >> 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.
I know, but the gallium EGL driver will still have to dlopen the gallium chipset driver. >> 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. I don't think any of those apply to libEGL. Could you list some of those reasons? Here's what I got: - Ability to switch the underlying implementation for entry points on the fly (for glBegin/End) - Ability to share libGL between different driver vendors (that is, closed source drivers could share the same libGL while sharing only minnal code), which never happened. Other than that, having the abstraction layer so high in the stack, is just really awkward. A more natural split would keep more code in libGL and only dlopen the driver specific parts. Essentially what ajax did with the dri_core hack in the Fedora RPMs, or you know, how gallium splits the core state tracker and the driver in two parts. And it's how libEGL is structured today: we have all the highl-level API logic in libEGL which then calls into the dlopened driver to make it happen. > 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. We already have that ability. That's what the egl/main / egl/drivers interface does. And we don't have to worry about binary compatibility there, we always build libEGL and drivers from the same mesa release. Mixing and matching libEGL and EGL drivers from different releases isn't allowed as it is for DRI drivers and there's no reason it should be. Kristian _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
