Manta Interactive Ray Tracer Development Mailing List

Text archives Help


[Manta] Re: Re: Re: parallel bvh


Chronological Thread 
  • From: Thiago Ize < >
  • To:
  • Cc: Thiago Ize < >
  • Subject: [Manta] Re: Re: Re: parallel bvh
  • Date: Tue, 08 Mar 2011 16:51:37 -0700
Actually, I've rewritten the lazy build so that it works really well now. There's very little overhead and it scales fairly well. If build time is at all an issue, then lazy build is now the way to go. I've committed my code and added an option to cmake to turn it on.

While I was mucking around in there I also fixed the approximate build which was not doing a correct SAH. Now the approx SAH should give much better results. That combined with a lazy build gives super fast builds.

The only major downsides I currently see with the lazy build is that it uses a bit more memory and that it doesn't scale perfectly since the top level of the tree is not built in parallel.
Thiago

Solomon Boulos wrote:
The problem is that my hacked-together task system allocates a ton of memory 
for all the parallel build tasks. If you were to actually want to use it, 
you'd want to create a memory pool for those tasks so that you can create and 
destroy them efficiently (and from multiple threads). Other than that it's 
sort of okay (as you can see from the reasonable-ish build).

Ultimately though, if you compared to the lazy build code (which Thiago 
reports as being busted now) you'd have pretty similar speedups without 
hassles (the only issue being that it's easy to do subtree parallelism with a 
lazy build, but hard to cooperate with the root-node construction which this 
code does).

Anyway, glad to see it still works 4 years later.

On Mar 8, 2011, at 3:42 PM, Carson wrote:

timings for dynBVH parallel build on 4-core nehalem.

dragon model: 0.87 million tri

np  seconds  speedup  efficiency
1:  1.08881  1           1
2: 0.594981  1.83        .915
3: 0.416616  2.57        .86
4: 0.346193  3.12        .78
8: 0.268632  4.01        0.5

Carson

On Tue, 2011-03-08 at 15:26 -0700, Thiago Ize wrote:
I don't really want to go through the hassle of getting the parallel code up and running only to then realize it's no good and remove it all. Easiest might be to revert to the previous version and then modify DynBVH.h so that computeBounds is

   void computeBounds(const PreprocessContext& context,
                      BBox& bbox) const
   {
     currGroup->computeBounds(context, bbox);
   }

That should hopefully do the trick and take you less than a minute to find out. Let me know if that still doesn't work.

Carson wrote:
it's now crashing with the recent changes I'll need to spend some time
debugging it.  Maybe later tonight.
Carson



Archive powered by MHonArc 2.6.16.

Top of page