Multiple EGL implementations

[Andy Ritger]

Dave: by "silly", I assume you mean "Linux OpenGL ABI compliant" ;)

Adam: I agree, technically, with your assessment of what would need
to be done to get to a point where there could be a common libGL.

However, Keith is right: for immediate-mode OpenGL applications,
the overhead of API dispatching is very significant.  Dispatching
through a common libGL is very undesirable for this (unfortunately
still quite common) usage case.

While I admit that having a common libGL and allowing multiple vendor
implementations to coexist is a noble goal, from a strictly IHV
standpoint this is not interesting (for obvious business reasons).

If nothing else, it would be good to resolve this issue to ease
installation of IHV OpenGL implementations.

The Linux OpenGL ABI working group has recently been revived, and Jon
Leech is working to hand off ABI specification to the LSB project.
Solving these problems through the Linux OpenGL ABI is probably
the most productive route.

Thanks,
- Andy


On Mon, 4 Jul 2005, Keith Whitwell wrote:

> Adam Jackson wrote:
> > On Monday 04 July 2005 08:57, Dave Airlie wrote:
> > 
> >>This is partly "our" fault the current libGL suffers from a lack of
> >>vendor extensibility ... Ian has been doing some serious work on
> >>making sure this doesn't happen for 6.9/7.0, and I believe ATI have
> >>been in contact with him to avoid their having to ship a separate
> >>libGL in the future..
> >>
> >>Then we'll just have to convince nvidia that they are being silly
> >>using their own one :-)
> > 
> > 
> > There's four issues, in my count.
> > 
> > Within the GL part of the interface, the dispatch table into the driver is 
> > probably not consistent.  The DRI-based drivers all use the Mesa dispatch 
> > table, but nVidia and Matrox appear not to (iirc).  Ian's work has been on 
> > making the Mesa dispatch more amenable to vendor extension.  That should make 
> > it general enough for the other vendors too.  The GL API is stable enough 
> > that there's really only a few ways to do this, and most of the issues would 
> > have to do with structure ordering.
> > 
> > Within the GLX part, some functions have different dispatch paths depending on 
> > whether it's a direct or indirect current context.   The DRI drivers have a 
> > fairly consistent interface for this (with a few vendor extensions to get 
> > features that aren't in the base libGL yet); the nVidia and Matrox interfaces 
> > here are a bit of a mystery.  We'd either need to standardize how we do GLX 
> > dispatch into the drivers, or have multiple paths for loading various types.
> > 
> > Implicit in the above is that all drivers have to agree what a GLX context 
> > structure looks like, and probably for drawables and one or two other types 
> > too.  Again, the DRI drivers have this pretty uniform, but who the hell knows 
> > what's going on with the other two.
> > 
> > And finally, all the code needs to be moved to the new design, which takes 
> > time and requires some buy-in from the vendors that we've gotten it right.
> > 
> > This is nothing new or hard, as a code matter it's just defining a driver 
> > interface with sufficient extensibility, and exposing the versioning 
> > properly.  It's work that needs to happen, because right now the situation 
> > with libGL is exactly the situation the X server was in in the 3.x days.
> > 
> 
> I believe nvidia manage to squeeze a few optimizations out of dispatch 
> as well, which would either have to be matched/duplicated if they are 
> clean enough or they'd have to be convinced to give up.  I don't know 
> how significant they are.
> 
> Keith
> _______________________________________________
> dri-egl mailing list
> dri-egl at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-egl
>