linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: [Linux-fbdev-devel] 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




  reply	other threads:[~2003-10-27 15:48 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 [this message]
2003-10-28 10:53                   ` Ingo Oeser
2003-10-27 15:14               ` Keith Whitwell
2003-10-27 15:38                 ` Jeff Garzik
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=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).