[Bf-committers] "Official" CUDA Benchmark/Implementation Thread
joeedh at gmail.com
Fri Dec 19 08:07:21 CET 2008
I always thought simply using the GPU to perform ray-intersection tests of
groups of triangles would be easier and possibly more practical, though
that's something you could speed up with basic SIMD instructions as well
(though sse and the like are a major pain to use).
If you're doing packets of rays, a separate thread per pixel is a bad
analogy (that would never work). I thought about this a while back (when I
was thinking of writing code to take advantage of the Cell processor) and a
simple queue system might be the best. This would be difficult to implement
without continuations, however.
On Thu, Dec 18, 2008 at 3:40 PM, Timothy Baldridge <tbaldridge at gmail.com>wrote:
> There's a issue with my last comment (and allot of typos in there
> too). The method I proposed would need the ability for the main render
> engine to fire all rays, then come back and gather the results. I
> don't think the current engine can do that. We have the bucket based
> multi-threading renderer, but what we're basically discussing is a
> seperate thread per pixel, and that's basically a total re-write of
> the engine, I bet.
> Two wrights don't make a rong, they make an airplane. Or bicycles.
> Bf-committers mailing list
> Bf-committers at blender.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-committers