Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Keith Whitwell <keith@tungstengraphics.com>]

Jeff Garzik wrote:
> Linus Torvalds wrote:
> 
>> Quite frankly, I'd much rather see a low-level graphics driver that does
>> _two_ things, and those things only:
>>
>>  - basic hardware enumeration and setup (and no, "basic setup" does not
>>    mean "mode switching": it literally means things like doing the    
>> pci_enable_device() stuff.
>>
>>  - serialization and arbitrary command queuing from a _trusted_ party (ie
>>    it could take command lists from the X server, but not from untrusted
>>    clients). This part basically boils down to "DMA and interrupts". 
>> This    is the part that allows others to wait for command completion, 
>> "enough    space in the ring buffers" etc. But it does _not_ know or 
>> care what the    commands are.
> 
> 
> Thank you for saying it.  This is what I have been preaching (quietly) 
> for years -- command submission and synchronization (and thus, DMA/irq 
> handling) needs to be in the kernel.  Everything else can be in 
> userspace (excluding hardware enable/enumerate, of course).

To enable secure direct rendering on current hardware (ie without secure 
command submission mechanisms), you need command valididation somewhere.  This 
could be a layer on top of the minimal dma engine Linus describes.

> Graphics processors are growing more general, too -- moving towards 
> generic vector/data processing engines.  I bet you'll see an optimal 
> model emerge where you have some sort of "JIT" for GPU microcode in 
> userspace.  

You mean like the programmable fragment and vertex hardware that has been in 
use for a couple of years now?

Keith