Messages in this thread | | | Date | Mon, 27 Oct 2003 15:14:11 +0000 | From | Keith Whitwell <> | Subject | Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |