linux-fbdev.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: 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/

  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).