Messages in this thread | | | Date | Sat, 25 Oct 2003 15:17:44 -0400 | From | Jeff Garzik <> | Subject | Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion |
| |
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).
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. Multiple apps pipeline X/GL/hardware commands into the JIT, which in turn pipelines data and microcode commands to the GPU kernel driver.
Jeff
- 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/
| |