Cycles: build Light Tree in parallel #105862

Merged
Weizhen Huang merged 4 commits from weizhen/blender:parallel_light_tree into main 2023-03-20 18:02:23 +01:00
3 changed files with 10 additions and 10 deletions
Showing only changes of commit 86cb473f11 - Show all commits

View File

@ -655,8 +655,8 @@ void LightManager::device_update_tree(Device *,
else {
/* Fill in the stacks. */
left_index_stack[stack_id] = index;
right_node_stack[stack_id] = node->children[right].get();
node = node->children[left].get();
right_node_stack[stack_id] = node->children[LightTree::right].get();
node = node->children[LightTree::left].get();
stack_id++;
}
}

View File

@ -226,7 +226,7 @@ LightTree::LightTree(vector<LightTreePrimitive> &prims,
root->children[right]->make_leaf(num_local_lights, num_distant_lights);
}
void LightTree::recursive_build(const LightTreeChild child,
void LightTree::recursive_build(const Child child,
LightTreeNode *parent,
brecht marked this conversation as resolved Outdated

Is there a reason this is a template argument instead of a regular function argument?

It's only used for parent->children[child], not worth specializing the function for as far as I can see.

Is there a reason this is a template argument instead of a regular function argument? It's only used for `parent->children[child]`, not worth specializing the function for as far as I can see.

It's also used for recursive_build<left>(current_node, start, middle, prims, bit_trail, depth + 1);, I think it looks better than recursive_build(0, current_node, start, middle, prims, bit_trail, depth + 1);

It's also used for `recursive_build<left>(current_node, start, middle, prims, bit_trail, depth + 1);`, I think it looks better than `recursive_build(0, current_node, start, middle, prims, bit_trail, depth + 1);`

I think this would look ok too?

recursive_build(left, current_node, start, middle, prims, bit_trail, depth + 1);

Generally there should be a performance reason for using templates like this. Not a big deal for any individual function, but still would rather not do it here.

I think this would look ok too? ``` recursive_build(left, current_node, start, middle, prims, bit_trail, depth + 1); ``` Generally there should be a performance reason for using templates like this. Not a big deal for any individual function, but still would rather not do it here.
const int start,
const int end,

View File

@ -53,12 +53,6 @@ OrientationBounds merge(const OrientationBounds &cone_a, const OrientationBounds
* The light tree construction is based on PBRT's BVH construction.
*/
/* Left or right child of an inner node. */
enum LightTreeChild {
left = 0,
right = 1,
};
/* Light Tree Primitive
* Struct that indexes into the scene's triangle and light arrays. */
brecht marked this conversation as resolved Outdated

This name is too generic to put in the global Cycles namespace. Should be either defined inside the LightTree class, or named LightTreeChild.

This name is too generic to put in the global Cycles namespace. Should be either defined inside the `LightTree` class, or named `LightTreeChild`.
struct LightTreePrimitive {
@ -139,6 +133,12 @@ class LightTree {
uint max_lights_in_leaf_;
public:
/* Left or right child of an inner node. */
enum Child {
left = 0,
right = 1,
};
LightTree(vector<LightTreePrimitive> &prims,
const int &num_distant_lights,
uint max_lights_in_leaf);
@ -169,7 +169,7 @@ class LightTree {
/* Do not spawn a thread if less than this amount of primitives are to be processed. */
enum { MIN_PRIMS_PER_THREAD = 4096 };
void recursive_build(LightTreeChild child,
void recursive_build(Child child,
LightTreeNode *parent,
int start,
int end,