clipka wrote:
> Competing writes to the tree hierarchy can be avoided - without all-too-frequent
> messing with locks - as follows:

Please note that finding a locking algorithm is not the problem. The issue 
at hand is significantly more complex: The heuristic deciding to reuse a 
sample or take a new sample simply breaks with multiple threads because it 
depends on the order threads retrieve samples and decide to add samples. 
This order in turn will lead to similar, but yet different trees each time 
the same scene is rendered because thread execution order is never 
predictable, let along controllable. As such, the image will look different 
unless very high sample qualities are used.

The solution here is either to only pretrace (single threaded then), order 
sample insertion (only feasible in a multithreaded pretrace), or come up 
with some other division of the tree avoiding insertion data race conditions.

	Thorsten

Post a reply to this message