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.