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

[Keith Whitwell]

On Fri, 2010-05-07 at 10:47 -0700, Jakob Bornecrantz wrote:
> 2010/5/7 Kristian Høgsberg <krh at bitplanet.net>:
> > 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.
> 
> They are statically linked.
> 
> >
> >>> 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)
> 
> Right this does not apply.
> 
> >
> >  - 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.
> 
> With my nVidia/ATI user hat on, that would be pretty neat, and untill
> we get good enough FOSS drivers for the hardware it would make it
> easier for everybody involved if this would happen.
> 
> Now only the people involved with the nVidia/ATI drivers can say for
> sure, but I wouldn't be surprised that it was due to us using a
> different glx implementation and/or them not using DRM/DRI. That is
> nothing to do with the dispatcher itself but the fact that libGL came
> bundled with other code that they didn't agree with.
> 
> >
> > 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.
> 
> It was a counter point to my own idea of just bundling egl/main
> egl_dri2 together in libEGL. That is with regards to that I like
> things to stay the way things are now.
> 
> > 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.
> >
> 
> With my VMware hat firmly on, mixing support, do want!

I think I have to say I don't have a clear idea how this relates to
anything we're doing at VMware.  

This looks like a discussion about how to split up the EGL stack into
loadable modules.  I'm sure there are pros and cons for making that
split at various levels, but it's not really valid to say that we've got
any sort of corporate opinion on that...

Basically it sounds like Jakob has an architecture he's interested in
pursuing, but this seems to be a bit of a round-about way of creating a
discussion about it.

Jakob -- Maybe the best thing to do would be to take a step back from
this change and really put some effort into describing what your desired
architecture is, how it differs from what's there now, what the
advantages & disadvantages are, and then have a proper discussion about
the whole thing?

Keith