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).<div>
<br></div><div>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.<br>
<div><br></div><div>Joe<br><br><div class="gmail_quote">On Thu, Dec 18, 2008 at 3:40 PM, Timothy Baldridge <span dir="ltr"><<a href="mailto:tbaldridge@gmail.com">tbaldridge@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
There's a issue with my last comment (and allot of typos in there<br>
too). The method I proposed would need the ability for the main render<br>
engine to fire all rays, then come back and gather the results. I<br>
don't think the current engine can do that. We have the bucket based<br>
multi-threading renderer, but what we're basically discussing is a<br>
seperate thread per pixel, and that's basically a total re-write of<br>
the engine, I bet.<br>
<div><div></div><div class="Wj3C7c"><br>
Timothy<br>
<br>
<br>
--<br>
Two wrights don't make a rong, they make an airplane. Or bicycles.<br>
_______________________________________________<br>
Bf-committers mailing list<br>
<a href="mailto:Bf-committers@blender.org">Bf-committers@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-committers" target="_blank">http://lists.blender.org/mailman/listinfo/bf-committers</a><br>
</div></div></blockquote></div><br></div></div>