From: Jeff Garzik <jgarzik@pobox.com>
To: Keith Whitwell <keith@tungstengraphics.com>
Cc: Linus Torvalds <torvalds@osdl.org>,
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: Mon, 27 Oct 2003 10:38:24 -0500 [thread overview]
Message-ID: <20031027153824.GA19711@gtf.org> (raw)
In-Reply-To: <3F9D3643.9030400@tungstengraphics.com>
On Mon, Oct 27, 2003 at 03:14:11PM +0000, Keith Whitwell wrote:
> Jeff Garzik wrote:
> >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.
Certainly.
> >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?
I mean, taking current fragment and vertex processing and making it
even _more_ general. Which has already happened, on one particular chip
maker's chip...
Jeff
next prev parent reply other threads:[~2003-10-27 15:38 UTC|newest]
Thread overview: 33+ 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 21:10 ` Eric Anholt
2003-10-23 21:31 ` Jon Smirl
2003-10-23 23:23 ` [Dri-devel] " Linus Torvalds
2003-10-23 23:46 ` Eric Anholt
2003-10-24 1:19 ` Jeff Garzik
2003-10-24 1:52 ` Jon Smirl
2003-10-24 3:47 ` Multiple drivers for same hardware:, was: " Jon Smirl
2003-10-24 4:40 ` Linus Torvalds
2003-10-28 18:00 ` James Simmons
2003-10-24 16:44 ` [Dri-devel] Re: [Linux-fbdev-devel] " Linus Torvalds
2003-10-24 16:57 ` Petr Vandrovec
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:08 ` Ivan Kokshaysky
2003-10-24 17:06 ` Jeff Garzik
2003-10-24 1:50 ` Jon Smirl
2003-10-25 17:29 ` Egbert Eich
2003-10-25 18:37 ` Linus Torvalds
2003-10-25 19:17 ` Jeff Garzik
2003-10-27 14:37 ` Ingo Oeser
2003-10-27 15:43 ` Jeff Garzik
2003-10-28 10:53 ` Ingo Oeser
2003-10-27 15:14 ` Keith Whitwell
2003-10-27 15:38 ` Jeff Garzik [this message]
2003-10-27 15:50 ` Keith Whitwell
2003-10-25 21:02 ` Jon Smirl
2003-10-25 22:07 ` Benjamin Herrenschmidt
2003-10-27 14:01 ` jlnance
2003-10-27 15:10 ` Eric W. Biederman
2003-10-27 15:10 ` Keith Whitwell
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=20031027153824.GA19711@gtf.org \
--to=jgarzik@pobox.com \
--cc=dri-devel@lists.sourceforge.net \
--cc=eich@xfree86.org \
--cc=eta@lclark.edu \
--cc=jonsmirl@yahoo.com \
--cc=keith@tungstengraphics.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).