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

[Kristian Høgsberg]

2010/5/7 Jakob Bornecrantz <wallbraker at 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