GPU

Joshua 'Schwa' Gargus schwa at cc.gatech.edu
Tue Nov 18 20:25:04 UTC 2003


On Tue, Nov 18, 2003 at 05:16:33PM -0200, Jecel Assumpcao Jr wrote:
> On Monday 17 November 2003 23:19, Joshua 'Schwa' Gargus wrote:
> > On Mon, Nov 17, 2003 at 09:28:01PM -0200, Jecel Assumpcao Jr wrote:
> > > [OpenGL vs REYES paper]
> > I read this quickly a while ago... wasn't one of the conclusions that
> > there were inherent inefficiencies in the Reyes model in the context
> > of a hardware implementation?
> 
> That is certainly one possible conclusion. But another way to looking at 
> it is that the vast gap of a few years ago is now only a more or less 
> large one. So we might extrapolate and consider that it is only a 
> matter of time before REYES starts invading OpenGL's turf.

That is a good way to look at it.  It is a starting point to ask how to
define an architecture that incorporates the best aspects of each.

> 
> > > [and slides]
> > I haven't seen this... I'll check it out.
> 
> It is the same thing, but with more pictures and less words :-)
> 
> > One thing about ray-tracing is that it inherently has bad memory
> > locality (for each pixel, you might have to test for intersection
> > against each object in your scene).  I don't see a way around this.
> 
> Since you mentioned Pat Hanrahan, you might find this paper from his 
> fall course's (CS448) reading list interesting:
> 
> http://graphics.cs.uni-sb.de/Publications/2002/Schmittler-AHardwareArchitectureForRayTracing.pdf

Thank you for the link.

> > I don't know if real-time ray-tracing/radiosity are desirable from
> > the point of view of amount of computation required. 
> 
> The question is: do they make prettier pictures?

The answer to that is yes.  

Another question is: will the extra computation required cause cards
capable of doing it to have extra power connectors?

;-)

> 
> > This is
> > especially true in the common case of mostly static scenes where
> > radiosity can be precomputed and stored in textures.  It's my
> > understanding that many current 1st person shooters use this
> > approach.
> 
> To be at least a little on topic, here, our focus should be on Croquet. 
> In that context precomputation conflicts with late binding.

That is true.  However, graphics is all about precomputation.  If I compute
vertices for a NURBS surface, I don't want to compute them again until the
surface is modified; even if I can write a vertex program to do it in
real-time, it is still a waste of GPU cycles.  By the same token, even if
we can compute radiosity each frame, it would be better to cache and reuse
it until the scene has changed enough to require recomputation.

However, I'll grant that this isn't exactly what I said the first time...
current games precompute the radiosity before shipping the game, and don't
"flush the cache" during the game.

If we restrict our focus to Croquet, it is not clear to me that photorealism
is nessary or desirable for the majority of applications.

> 
> But where such tricks can be used, then I am all for them.
> 
> > I'm always interested in hearing new ideas.  (I'm very excited that I
> > get to hear a talk on the topic by Pat Hanrahan this Thursday).
> 
> Enjoy!

Thanks!

Joshua


> 
> -- Jecel



More information about the Squeak-dev mailing list