From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262770AbTJYTSA (ORCPT ); Sat, 25 Oct 2003 15:18:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262774AbTJYTSA (ORCPT ); Sat, 25 Oct 2003 15:18:00 -0400 Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:18121 "EHLO www.linux.org.uk") by vger.kernel.org with ESMTP id S262770AbTJYTR7 (ORCPT ); Sat, 25 Oct 2003 15:17:59 -0400 Message-ID: <3F9ACC58.5010707@pobox.com> Date: Sat, 25 Oct 2003 15:17:44 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 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 Subject: Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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 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/