Text archives Help

---

Yes, see DynBVH::rebuild or Grid::rebuild before a couple days ago:

BVH issue:

PreprocessContext context;

 if(currGroup && currGroup->size() == group->size()) {
   currGroup = group;
   parallelUpdateBounds(context, proc, numProcs);
 }

Grid issue:

void Grid::rebuild(Group *group, int proc, int numProcs)
{
 currGroup = group;

 if (proc == 0) {
   startGlobalBuildTime = SCIRun::Time::currentSeconds();
preFrameSetup(proc, numProcs); //currGroup size might have changed }


Both have race conditions where every thread assigns currGroup = group. So that's why I separated them. In addition to this part, there was another one in KeyframeAnimation.cc::update:


   else if (interpolation == truncate) {
       currGroup = frames[(int) frame];
   }
   if (as)
     as->rebuild(currGroup, context.proc, context.numProcs);

In this case, all the threads will set currGroup to be the same value (frames[(int)frame]) but will race on doing so and then race to call rebuild on the accel structure. This is the calling case that triggered the DynBVH::rebuild issue.

As I mentioned in the sweeping commit email, this isn't done yet; it just shouldn't break (other than compilation of outside projects that rely on rebuild and update outside of KeyframeAnimation). The computeBounds stuff still isn't finished either, since it seems overly restrictive to only allow computeBounds calls during a preprocess (conceptually only occurs once after scene load); obviously update/rebuild are definitely going to need an efficient way to handle computeBounds and do so in parallel if possible. Feedback on this would be appreciated.

Solomon

Thiago Ize wrote:

Do you have an example of a race condition that was occurring? There have been some sweeping changes lately and I'm not sure how they are supposed to work (i.e. parallel preprocess context).

Thiago

Solomon Boulos wrote:

Yep. When "building your scene", you should really only be doing things like setting up pointers (so say, "I'm going to eventually build a BVH over this Mesh") and have it be a low/zero cost operation.

Since rebuild is meant to be called in parallel as well (every thread calls it), it's dangerous to have a race condition amongst the threads where you change what the current group is. So instead, you should change the current working group using setGroup and then run rebuild in parallel.

I'm guessing this broke an outside project... sorry about that.

Solomon

Ingo Wald wrote:

hi all,

is there any reason why AccelStructure's rebuidl(group, ...) was split into a setGroup() and rebuild(...) combo ?

Ingo

---

• [Manta] changes to AccelStructure.h, Ingo Wald, 08/21/2007
  • Re: [Manta] changes to AccelStructure.h, Solomon Boulos, 08/21/2007
    • Re: [Manta] changes to AccelStructure.h, Thiago Ize, 08/21/2007
      • Re: [Manta] changes to AccelStructure.h, Solomon Boulos, 08/21/2007

---

Archive powered by MHonArc 2.6.16.