libdrm issues blocking accelerated indirect GL

[Thomas Hellström]

Adam Jackson wrote:

>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.
>
>  
>
In this discussion it's important to not forget non-OpenGL dri clients. 
Both lib810XvMC and libviaXvMC use libdrm code, but they actually 
symlink  only needed source files from the libdrm source and compile 
them directly into the library. I see no reason, however, why they 
shouldn't be able to use a dynamic so instead.

Common X server DDX calls to libdrm are:

Open
Authentication
map adding / removal
agp alloc / free / bind / unbind /map /unmap
irq enabling / disabling
locking / unlocking
drmCommandWrite / Read for vendor-specific functionality.

Some of these, but not all, can be done by the drm itself, as Jon mentions.

/Thomas

>- ajax
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>xorg mailing list
>xorg at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/xorg
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20041231/15067b5d/attachment.html>