All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Egbert Eich <eich@xfree86.org>, Jon Smirl <jonsmirl@yahoo.com>,
	Eric Anholt <eta@lclark.edu>,
	kronos@kronoz.cjb.net,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fbdev-devel@lists.sourceforge.net,
	dri-devel <dri-devel@lists.sourceforge.net>
Subject: Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
Date: Sat, 25 Oct 2003 15:17:44 -0400	[thread overview]
Message-ID: <3F9ACC58.5010707@pobox.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0310251116140.4083-100000@home.osdl.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




WARNING: multiple messages have this Message-ID (diff)
From: Jeff Garzik <jgarzik@pobox.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Egbert Eich <eich@xfree86.org>, Jon Smirl <jonsmirl@yahoo.com>,
	Eric Anholt <eta@lclark.edu>,
	kronos@kronoz.cjb.net,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fbdev-devel@lists.sourceforge.net,
	dri-devel <dri-devel@lists.sourceforge.net>
Subject: Re: [Dri-devel] Re: DRM and pci_driver conversion
Date: Sat, 25 Oct 2003 15:17:44 -0400	[thread overview]
Message-ID: <3F9ACC58.5010707@pobox.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0310251116140.4083-100000@home.osdl.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





-------------------------------------------------------
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/

  reply	other threads:[~2003-10-25 19:18 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-21  2:31 DRM and pci_driver conversion Eric Anholt
2003-10-23 19:04 ` [Linux-fbdev-devel] " Kronos
2003-10-23 19:04   ` Kronos
2003-10-23 21:10   ` [Linux-fbdev-devel] " Eric Anholt
2003-10-23 21:31     ` Jon Smirl
2003-10-23 23:23       ` [Dri-devel] " Linus Torvalds
2003-10-23 23:23         ` Linus Torvalds
2003-10-23 23:46         ` Eric Anholt
2003-10-24  1:19         ` Jeff Garzik
2003-10-24  1:19           ` [Dri-devel] " Jeff Garzik
2003-10-24  1:52           ` [Dri-devel] Re: [Linux-fbdev-devel] " Jon Smirl
2003-10-24  3:47           ` Multiple drivers for same hardware:, was: " Jon Smirl
2003-10-24  3:47             ` Jon Smirl
2003-10-24  4:40             ` Linus Torvalds
2003-10-24  4:40               ` Linus Torvalds
2003-10-28 18:00               ` James Simmons
2003-10-28 18:00                 ` James Simmons
2003-10-24 16:44           ` [Dri-devel] Re: [Linux-fbdev-devel] " Linus Torvalds
2003-10-24 16:44             ` [Dri-devel] " Linus Torvalds
2003-10-24 16:57             ` [Dri-devel] Re: [Linux-fbdev-devel] " Petr Vandrovec
2003-10-24 17:59               ` Linus Torvalds
2003-10-24 17:59                 ` Linus Torvalds
2003-10-24 18:34                 ` Jon Smirl
2003-10-24 19:45                   ` Ivan Kokshaysky
2003-10-24 19:45                     ` [Dri-devel] " Ivan Kokshaysky
2003-10-24 19:08               ` [Dri-devel] Re: [Linux-fbdev-devel] " Ivan Kokshaysky
2003-10-24 19:08                 ` [Dri-devel] " Ivan Kokshaysky
2003-10-24 17:06             ` [Dri-devel] Re: [Linux-fbdev-devel] " Jeff Garzik
2003-10-24 17:06               ` [Dri-devel] " Jeff Garzik
2003-10-24  1:50         ` [Dri-devel] Re: [Linux-fbdev-devel] " Jon Smirl
2003-10-24  1:50           ` [Dri-devel] " Jon Smirl
2003-10-25 17:29         ` [Dri-devel] Re: [Linux-fbdev-devel] " Egbert Eich
2003-10-25 17:29           ` [Dri-devel] " Egbert Eich
2003-10-25 18:37           ` [Dri-devel] Re: [Linux-fbdev-devel] " Linus Torvalds
2003-10-25 18:37             ` Linus Torvalds
2003-10-25 19:17             ` Jeff Garzik [this message]
2003-10-25 19:17               ` [Dri-devel] " Jeff Garzik
2003-10-27 14:37               ` Ingo Oeser
2003-10-27 14:37               ` [Dri-devel] Re: [Linux-fbdev-devel] " Ingo Oeser
2003-10-27 15:43                 ` Jeff Garzik
2003-10-27 15:43                   ` [Dri-devel] " Jeff Garzik
2003-10-28 10:53                   ` [Dri-devel] Re: [Linux-fbdev-devel] " Ingo Oeser
2003-10-27 15:14               ` Keith Whitwell
2003-10-27 15:14                 ` [Dri-devel] " Keith Whitwell
2003-10-27 15:38                 ` Jeff Garzik
2003-10-27 15:38                 ` [Dri-devel] Re: [Linux-fbdev-devel] " Jeff Garzik
2003-10-27 15:50                   ` [Dri-devel] " Keith Whitwell
2003-10-27 15:50                   ` [Dri-devel] Re: [Linux-fbdev-devel] " Keith Whitwell
2003-10-25 21:02             ` Jon Smirl
2003-10-25 21:02               ` [Dri-devel] " Jon Smirl
2003-10-25 22:07             ` [Dri-devel] Re: [Linux-fbdev-devel] " Benjamin Herrenschmidt
2003-10-25 22:07               ` [Dri-devel] " Benjamin Herrenschmidt
2003-10-27 14:01             ` [Dri-devel] Re: [Linux-fbdev-devel] " jlnance
2003-10-27 15:10             ` Eric W. Biederman
2003-10-27 15:10               ` [Dri-devel] " Eric W. Biederman
2003-10-27 15:10             ` [Dri-devel] Re: [Linux-fbdev-devel] " Keith Whitwell
2003-10-27 15:10               ` [Dri-devel] " Keith Whitwell
     [not found]             ` <20031027114006.A66611@xfree86.org>
2003-10-27 19:38               ` Ian Romanick
2003-10-27 21:32                 ` Linus Torvalds
2003-10-27 23:55                   ` Benjamin Herrenschmidt
2003-10-28  2:13                     ` Linus Torvalds
2003-10-28  3:27                       ` Philip Brown
2003-10-28 19:40                       ` James Simmons
2003-10-28 21:35                         ` Benjamin Herrenschmidt
2003-10-28 22:09                           ` Jon Smirl
2003-10-28 22:26                             ` Benjamin Herrenschmidt
2003-10-28 22:54                         ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F9ACC58.5010707@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=eich@xfree86.org \
    --cc=eta@lclark.edu \
    --cc=jonsmirl@yahoo.com \
    --cc=kronos@kronoz.cjb.net \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.