From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: [Dri-devel] Re: DRM and pci_driver conversion Date: Sat, 25 Oct 2003 15:17:44 -0400 Sender: linux-fbdev-devel-admin@lists.sourceforge.net Message-ID: <3F9ACC58.5010707@pobox.com> References: Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Errors-To: linux-fbdev-devel-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Linus Torvalds Cc: Egbert Eich , Jon Smirl , Eric Anholt , kronos@kronoz.cjb.net, Kernel Mailing List , linux-fbdev-devel@lists.sourceforge.net, dri-devel 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 ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/