Multiple EGL implementations

[Keith Whitwell]

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