Stackless kd-tree traversal back
(L) [2007/05/24] [Phantom] [Stackless kd-tree traversal] Wayback!The GPUs are taking over:
[LINK http://graphics.cs.uni-sb.de/Publications/TR/2007/StatelessTrav.pdf]
CPUs benefit too, according to the paper.
There are some scary numbers in the paper: Already, the GPU now does 11M rays/s, but they have a huge unidentified bottleneck somewhere.
_________________
--------------------------------------------------------------
Whatever
(L) [2007/05/24] [toxie] [Stackless kd-tree traversal] Wayback!i wouldn't say they're taking over..
a) now the tree construction takes even longer as it did before (add ropes)
b) the mysterious bottlenecks they encountered are inherent to the principle of GPUs: make "neighbouring" threads -not- do exactly the same work, voila, performance drops by a factor of 100 or so.
just my two cents
_________________
The standards are being lowered, not just on the internet, but in all of news and media.
(L) [2007/05/24] [tbp] [Stackless kd-tree traversal] Wayback!I must say i haven't properly done my homework on all those GPU traversals but fundamentally, as Toxie pointed out, they are even more sensitive than cpu to incoherent loads.
But i wonder why one would bother with kd+ropes when there's bvh+skip; i would really appreciate a clue here.
Anyway, while an admirable stunt it's just a transient result as the Wheel keeps turning; gimme those 80 cores already.
_________________
May you live in interesting times.
[LINK https://gna.org/projects/radius/ radius] | [LINK http://ompf.org/ ompf] | [LINK http://ompf.org/wiki/ WompfKi]
(L) [2007/05/24] [toxie] [Stackless kd-tree traversal] Wayback!what tbp said (-> BVH+skip)
_________________
The standards are being lowered, not just on the internet, but in all of news and media.
(L) [2007/05/24] [Phantom] [Stackless kd-tree traversal] Wayback!One thing that suprised me is the fact that they claim to have surpassed CPU tracing, with 11M rays on a GPU, which they say is better than their result for 4 cores. They are not exactly talking about heavy scenes either. On four cores, I can quite easily do better than 11M rays... That being said: GPUs are quickly approaching CPU ray tracing performance. It used to be more like 1M for GPU, 10M for CPU.
Perhaps someone should write a ray tracer that uses both? [SMILEY Smile]
_________________
--------------------------------------------------------------
Whatever
(L) [2007/05/24] [tbp] [Stackless kd-tree traversal] Wayback!Found some hints for the kd/bvh+skip debate: [LINK http://gamma.cs.unc.edu/GPGP/lectures/RTGPU.ppt]
(L) [2007/05/24] [toxie] [Stackless kd-tree traversal] Wayback!if you must traverse the tree in exactly the wrong order and everything else goes wrong you get that O(n), but i doubt that this ever happens in real life.
the last one i'm not sure about.. i would say that this is not right..
_________________
The standards are being lowered, not just on the internet, but in all of news and media.
(L) [2007/05/25] [rogon] [Stackless kd-tree traversal] Wayback!Given that any real scene will have a depth-complexity of more than 5, I fail to see how this technique can be useful for anything more than trivial demo scenes.
Basically, BVH+skip = for each ray {find all boxes the ray goes through accumulating the minimum value}. There is no early out. I can't see how this would work well in any practical scene.
Rogon.
(L) [2007/05/26] [toxie] [Stackless kd-tree traversal] Wayback!as tbp said, you can fix that in the construction phase, as after all we're going for dynamic scenes, so a rebuild per frame must be possible.
_________________
The standards are being lowered, not just on the internet, but in all of news and media.
(L) [2007/11/16] [tbp] [Stackless kd-tree traversal] Wayback!Final version of the paper here: [LINK http://www.mpi-inf.mpg.de/~guenther/StacklessGPURT/]
_________________
May you live in interesting times.
[LINK https://gna.org/projects/radius/ radius] | [LINK http://ompf.org/ ompf] | [LINK http://ompf.org/wiki/ WompfKi]
back