Manta Interactive Ray Tracer Development Mailing List

Text archives Help


[Manta] Re: Info about Manta multi-threading


Chronological Thread 
  • From: Abe Stephens < >
  • To:
  • Cc: Biagio Cosenza < >
  • Subject: [Manta] Re: Info about Manta multi-threading
  • Date: Fri, 5 Jun 2009 13:27:05 -0600
Hi, I've added comments inline.

On Jun 5, 2009, at 9:47 AM, Biagio Cosenza wrote:

1st)
Is there in Manta code (maybe in Core/Thread ?) something to easily implement this:

if(I'm the first thread arrived here){
  //  do something
}

instead of

if(context.proc == 0){
  //  do something
}


I don't think this construction occurs anywhere in the code, but it should be possible using the methods in Semaphore, e.g. if (semaphore.tryDown()) { // I'm the first. }. Of course the semaphore would need to be incremented from a safe place earlier in the render loop, perhaps in an animation callback.


2nd)
I implemented two ImageTraverser using different load balancing strategy: the first using the WorkQueue approach (with granularity=5), the latter using a trivial static scheduling of packet between threads.

I also tested these two balancer on 3 complex scenes (from 200 000 to 8 000 000 of primary rays + reflections).

The test platform is an Intel Core 2 Quad Q6600 (4 cores).
Surprisingly scalability is higher with the static approach...
am I using the WorkQueue in the wrong way? Which is the better load balancer available in Manta for my target platform?

The better load balancing approach is probably more dependent on the graphics workload than on the hardware platform.  The rendering cost can be visualized by pressing 't' and then using 't+ctrl' or 't+shift' to adjust the color map. How does changing granularity effect scalability?


I also noted that the scalability is fine with low fps (close to 4x), but it slow down for higher fps (3x).

What are the actual refresh rates for low and high? Also what changes to produce the lower or higher frame rate, i.e. does the scene become more complicated, the output resolution greater etc.?

I wonder if this is due to a relatively higher cost of the barrier synch.

The barriers only become expensive if there is another source of load imbalance in the pipeline which the load balancer is unable to compensate for, e.g. the animation callbacks occur in a separate section of the control loop from rendering, so if one thread executes a very expensive animation update, the other threads might end up idling at the barrier which would hurt scalability. This type of load imbalance is usually visible in a profiler.


Abe



Archive powered by MHonArc 2.6.16.

Top of page