CUDA real-time path tracing demo

From all the reviews it appeared that the path tracing performance of the GTX 680 would be abysmal and far below expectations (worse than GTX 580), but I just found this CUDA path tracing benchmark (thanks to toxie from ompf forum) comparing GTX 480 and GTX 680, which looks a bit more promising: http://www.tml.tkk.fi/~timo/HPG2009/index.html

 

So almost 2x faster than the 480? That is pretty impressive if you ask me. It seems like the 680 is a bit of a puzzle...supposed to suck at path tracing and things like CFD; but excels at them in certain tests and does poorly in others. Seems like the code just needs to be optimized for kepler..then it's off the the races!!

 

From what I understand it sucks as long as you try to use doubles. As long as you stay with floats (and compiler actually spits out something usable) it's awesome.

 

So, they are using the tex cache for the fetches on Kepler? One must wonder why. If NV was to follow their architectural plan from Fermi, a single SMX in Kepler now should boast at least 48KB of tex streaming cache with corresponding increase of the access ports, that better track the increased compute throughput than the L1d cache.

 

From what I understand, this current Kepler, has been optimized for fast texturing, sacrificing L1/lL2 cache and shared memory in the process. For graphics this is a win but for compute algorithms relying on CPU like caches it hurts.
I'm still curious how current path tracing optimized for Fermi runs on Kepler.

 

Probably the same or worse, but that's not really relevant. A GPU path tracer that was developed and optimized on GT200 GPUs using "persistent threads" didn't run well on Fermi either . Unfortunately, every new GPU architecture requires a rewrite of the path tracing code to attain maximum (or even better) performance.

 

The thing is Fermi already had like two architectures:
- GF114 aka GTX 560
- GF110 aka GTX 580
The former has 8 SM the latter has 16 SM, also 256 bus vs 384 bus.
The former also shed compute in favor of graphics.
Now we have the GTX 680, which misleadingly sounds like the GPU is a derivative of GF110, but it is not. GPU marketing department (of both NV and ATI) is rather creative in a sense.
The GTX 680 is based on the GK104 which is like a supercharged GF114, and thus also not very well tuned at compute. Likely there will still be a GK114, think big monster chip, with wide memory bus. As the 28nm process still has too low yield for such a big chip, it has been postponed...

 

Ok, mistake above:
Logically the next big Kepler compute chip would be GK100

GF100 -> GF110 -> GK100 big chip compute optimized
GF104 -> GF114 -> GK104 smaller chip graphics optimized

 

One thing that is not clear to me : why do you say that a bidirectional path tracer scales better than rasterization... why do you say that a path tracer scales better than rasterization?

ps: sorry for necro but the topic is interesting

 

It is somewhat an old idea, probably based on the fact that ray/triangles intersection algorithm is O(log triangles_count).

I'm not sure if this argument is still valid nowadays.

I prefer arguments based on the quality, scene complexity and easy of use of (bidir) path tracing over classic rasterization. Real-time path tracing is already a viable option for simple scenes and I have yet to see a game engine that can match the quality of good path tracer.

May be my opinion is biased but the renderings of today game engines still look too "fake" to me.