From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Whitwell Subject: Re: [Dri-devel] Re: DRM and pci_driver conversion Date: Mon, 27 Oct 2003 15:14:11 +0000 Sender: linux-fbdev-devel-admin@lists.sourceforge.net Message-ID: <3F9D3643.9030400@tungstengraphics.com> References: <3F9ACC58.5010707@pobox.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <3F9ACC58.5010707@pobox.com> 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: Jeff Garzik Cc: Linus Torvalds , Egbert Eich , Jon Smirl , Eric Anholt , kronos@kronoz.cjb.net, Kernel Mailing List , linux-fbdev-devel@lists.sourceforge.net, dri-devel 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 ------------------------------------------------------- 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/