For every pass of the rendering algorithm, a list of blocks is distributed among the available processors. A straight-forward approach for this distribution is to simply divide the list into equally sized portions. This works well if the algorithm does not use any optimizations for skipping empty space. However, employing the optimizations presented in the previous sections can lead to a very unequal distribution, and thus, reduce the performance gains due to using multiple CPUs.
We use a simple estimate to determine the computational effort required for processing a whole block. For a list of blocks we compute for each block :
(3.16) |
is the number of rays entering the block and is a measure for the number of transparent samples in the block. An estimate measure for the transparency can be retrieved from the classified min-max octree. Depending on how many octree levels are taken into account, the estimate will become more accurate. For example, a simple way to obtain such a measure is to sum up the transparency information of the top-level octree nodes by counting fully transparent nodes as , fully opaque nodes as , and inhomogeneous nodes as . The factor determines the fraction of processing cost between a fully opaque and a fully transparent block. If is 0, the cost of processing an opaque and a transparent block is the same, if is 1, the cost of processing a fully transparent block is half the cost of processing a fully opaque block.
We then want to find a partition of for CPUs, so that the workload for each CPU is approximately equal. We sort all blocks in descending order of . A greedy algorithm then traverses the sorted list and always assigns a block to the CPU with the smallest current load, until all blocks have been assigned to a CPU. This approximative algorithm results in better balanced loads while introducing little overhead.