From: Jeff Garzik <jgarzik@pobox.com>
To: Ingo Oeser <ioe-lkml@rameria.de>
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>,
Linus Torvalds <torvalds@osdl.org>
Subject: Re: [Dri-devel] Re: DRM and pci_driver conversion
Date: Mon, 27 Oct 2003 10:43:09 -0500 [thread overview]
Message-ID: <20031027154309.GB19711@gtf.org> (raw)
In-Reply-To: <200310271537.30435.ioe-lkml@rameria.de>
On Mon, Oct 27, 2003 at 04:37:30PM +0200, Ingo Oeser wrote:
> On Saturday 25 October 2003 21:17, Jeff Garzik wrote:
> > 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.
>
> These "JIT" is needed also for another reason:
>
> There are contraints for GPU commands and the pipelines need to
> be modelled, like CPU piplines are modelled in a compiler. But
> more like the pipelines of some early long instruction word
> processors, where issuing to a used pipeline will cause random
> behavior and crashes. So the JIT doesn't should also emit
> synchronization points.
>
> With this JIT in place, there need to be just some hardware description
> files (backends) and some API (GL, DirectX, X) description files
> (frontends).
I agree 60% ;-) This JIT emits GPU-specific microcode, so it should
lean towards being hardware-dependent. Speed and efficiency IMO demand
that.
Looking at existing, open-source CPU JITs, there are certainly general
pieces and CPU-specific pieces. But for GPUs, I think the best method
is to start at the more-GPU-specific end of the spectrum, and _evolve_
towards a more general solution, as hardware needs dictate.
In other terms, let the hardware drive the JIT design and evolution, and
don't over-design for a future that may never come. That was part of
GGI's problem, IMO.
> Now we just need some funding for that and the datasheets. Then it's
> doable.
Yep ;-)
> I see just one showstopper: Cheating in benchmarks isn't possible anymore.
>
> PS: That's basically the GGI approach taken further.
I followed GGI for a while. Trying to be all things to all people was
their principle mistake. As Pat Morita said in Karate Kid,
"Focus, Daniel-san!" Be specific before general.
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/
next prev parent reply other threads:[~2003-10-27 15:43 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1066703516.646.24.camel@leguin>
2003-10-23 19:04 ` DRM and pci_driver conversion 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:46 ` Eric Anholt
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 4:40 ` Linus Torvalds
2003-10-28 18:00 ` James Simmons
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 18:34 ` Jon Smirl
2003-10-24 19:45 ` [Dri-devel] " 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 ` [Dri-devel] Re: [Linux-fbdev-devel] " Linus Torvalds
2003-10-25 19:17 ` [Dri-devel] " Jeff Garzik
2003-10-27 14:37 ` Ingo Oeser
2003-10-27 15:14 ` Keith Whitwell
2003-10-27 15:38 ` Jeff Garzik
[not found] ` <20031027153824.GA19711@gtf.org>
2003-10-27 15:50 ` Keith Whitwell
[not found] ` <200310271537.30435.ioe-lkml@rameria.de>
2003-10-27 15:43 ` Jeff Garzik [this message]
2003-10-28 10:53 ` [Dri-devel] Re: [Linux-fbdev-devel] " Ingo Oeser
2003-10-25 21:02 ` [Dri-devel] " Jon Smirl
2003-10-25 22:07 ` Benjamin Herrenschmidt
2003-10-27 15:10 ` Eric W. Biederman
2003-10-27 15:10 ` 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=20031027154309.GB19711@gtf.org \
--to=jgarzik@pobox.com \
--cc=dri-devel@lists.sourceforge.net \
--cc=eich@xfree86.org \
--cc=eta@lclark.edu \
--cc=ioe-lkml@rameria.de \
--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 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).