Manta Interactive Ray Tracer Development Mailing List

Text archives Help


[Manta] Re: Re: Re: Re: parallel bvh


Chronological Thread 
  • From: Aaron Knoll < >
  • To:
  • Subject: [Manta] Re: Re: Re: Re: parallel bvh
  • Date: Tue, 8 Mar 2011 20:02:34 -0600
Sounds pretty typical for most algorithms that run "at scale" :P

On Mar 8, 2011, at 7:57 PM, Carson wrote:

> it scales well, unfortunately for a 50MB file it was allocating over 10
> GB of memory and is getting a 20th the runtime performance.
> Carson
> 
> On Tue, 2011-03-08 at 15:46 -0800, 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