Page 1 of 1


Posted: Sun Jan 08, 2012 10:38 pm
by Vilem Otte

I've recently started some serious development in OpenCL and ray-tracing (finally got some time). And I'm pretty much stuck in BVHs on GPUs. I've been using (for quite a long time) CPU version of BVH, and now I'm porting to GPU.

So in which state am I - currently I build BVH on CPU and pass it to GPU (is this okay? is this common way to do it?).

Next thing I did was to write traversal, I did very simple one (with Todo stack one - just like PBRT does) and the GPU has frozen (I think that GPU doesn't go well with while(1) loop). Note that the scene is actually just some 300 triangle one (and I can render it smoothly in OpenCL without any hierarchy). I'm sure my BVH build process is okay, as I'm using it with CPU ray tracer without any problems (and it is quite fast).

Do you have any papers/articles/advices on how-to implement BVH + BVH traversal on GPUs?

Re: BVH on GPU

Posted: Mon Jan 09, 2012 8:59 am
by spectral
You can do it the same way you do on the CPU ! Do you use an ATI card ? Because if you lock a thread you will lock your video card and you have to reboot :-P
With NVidia card it is easier... they have a system yo avoid this !

You can, by example, take a look at the SLG code too :

What you can also do is to take a look at some more advanced code, like :
"Understanding efficiency of ray traversal on the GPU" : ... l-on-gpus/
"Out-of-core GPU Ray Tracing of Complex Scenes" :

Re: BVH on GPU

Posted: Mon Jan 09, 2012 6:47 pm
by Vilem Otte
Thanks for info (especially on thread-locking, It'll help me a lot in next stages of development), the problem was (suprisingly) absolutely elsewhere than I thought (searched) for it.

I finally found that it was in place, where I rewritten BVH structure to something more suitable for GPU (e.g. flattening it, optimizing struct sizes, etc.) and I've rewritten something in a wrong way. Then I was searching for child with illogical ID, one move through gdb gave me all info I needed (and I was searching the problem in OpenCL code throughout the night :mrgreen:).

And now let's optimize! (It is starting to be "bloody fast") :twisted: