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
WARNING: multiple messages have this Message-ID (diff)
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:48 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 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 [this message] 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=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: linkBe 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.