libdrm issues blocking accelerated indirect GL

[Adam Jackson]

On Thursday 30 December 2004 21:44, Jon Smirl wrote:
> I've been out of the DRI loop for a while since all I do is help feed
> and change two crying babies, but we also need think about the GL
> standalone case. libdrm is linked into the dri.so's so that they can
> be used standalone. Wouldn't another solution be to just fix the
> DRI.so's to not export the libdrm symbols?

Maybe.  Depends on if the linker would choose to resolve the drm symbols from 
the server's libdrm module or from the ones linked statically into the 
driver.  But then you still have two copies of the same code in the same 
process and attempting to use the same symbols, and to me that sounds like a 
design issue.

> If we proceed down the X on 
> GL path this problem would go away since X would stop using libdrm.

No, it won't.  For X on GL, the server still loads a DRI driver.  It's just 
already loaded early during eglCreateContext or whatever, rather than loaded 
explicitly by libglx.  The server still needs to be a window system for the 
5000 GLX applications that already exist, and we'll still want to be able to 
do accelerated indirect GLX.

> Since I haven't looked at the code in a month, can someone remind me
> why X needs to directly access libdrm and not use a DRI interface? For
> example the whole drmOpen sequence of where X searches for and loads
> DRM drivers would just go away if we let the OS automatically load the
> drivers based on PCI IDs. The current Linux DRM driver supports this.

Several of the DDXes and libdri call into libdrm.  I don't have a good 
enumeration of why they do that though.

Even in an X-on-GL world, you need a server process, and that server will want 
to act as a GL renderer for indirect clients.  Fixing libglx to use a DRI 
driver as the renderer (instead of GLcore) should in fact make an Xgl server 
simpler.

- 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/20041230/d1005e40/attachment.pgp>