Multiple EGL implementations

[Adam Jackson]

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.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dri-egl/attachments/20050704/8786bdab/attachment.pgp