libdrm issues blocking accelerated indirect GL

[Adam Jackson]

On Friday 31 December 2004 06:04, Michel Dänzer wrote:
> On Thu, 2004-12-30 at 14:20 -0500, Adam Jackson wrote:
> > - Option 3: Move libdrm from the DRI drivers into libGL (dlopen linkage)
> > Pros: Minimal server impact.  New libdrm could be shared between client
> > and server.  With a little cleverness [2], doesn't break the libGL/driver
> > ABI, so drivers and libGLs from both sides of the change can be mixed
> > freely.
>
> How would this work with an old libGL and a new driver?

Ack, it doesn't.  Good catch.  The only way would be 
LD_PRELOAD=/usr/lib/libdrm.so, but that's not acceptable.  Since the drivers 
are opened RTLD_NOW there's no chance for the driver to detect this, and the 
scenario assumes no changes to libGL.  However the LIBGL_DEBUG message would 
almost certainly mention a missing drm symbol, which might be good enough if 
we add it to the (desperately in need of cleanup) troubleshooting FAQ.

That may be a sacrifice I'm willing to make.  People using releases would get 
matching sets.  Even people building DRI drivers from Mesa will always get 
matching sets.  If the snapshots (wherever they live now) don't include libGL 
in the driver pack, they probably should.

For options 1-3, totally switching this over may be an X11R7 kind of thing 
where we break APIs in the name of progress.  However...

> Otherwise, this sounds best to me, or option 5 maybe.

I think I'm leaning towards options 4 or 5, as having minimal impact now.  In 
the future we'd link the server against libdrm (or the drivers, in a dlloader 
world) and ignore Load statements for drm and GLcore.  (dexconf generates 
config files with explicit load statements for drm and GLcore, even though it 
shouldn't.)  By that point libdrm would have a canonical location in the 
filesystem, so it would be a true shared object.

All of this really makes me want to revive debrix-extensions-glx.  Hacking 
this stuff from within the monolith is such a hassle.

- 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.x.org/archives/xorg/attachments/20041231/47a0bf01/attachment.pgp>