Am 01.07.2011 19:18, schrieb Thorsten Froehlich:
> On 01.07.11 12:24, Jack Burton wrote:
>>> I am not sure why you would want to globally share mutexes, and I am not
>>> sure what lists you are referring to specifically, so i cannot really
>>> give
>>> you an answer here.
>>
>> I'm referring to the lists (e.g. blockBusyList) and mutexes (e.g.
>> nextBlockMutex) in view.h.
>>
>> The idea of sharing the lists and mutexes is to record which blocks
>> which have
>> been rendered and which blocks are being rendered, so all of the
>> slaves in the
>> distributed setup can render the correct block and avoid duplication
>> of blocks
>> and avoid unnecessary communication. The mutex (as I understand it) is
>> to stop
>> the local threads accessing the lists at the same time, so this would
>> be needed
>> for a distributed scenario, too; basically the lists need to be
>> thread-safe
>> across multiple slaves.
>
> Well, it depends on your radiosity needs, but as you cannot distribute
> the radiosity data anyway, you are restricted to recomputed radiosity
> samples. Thus, you can simply remove those lists and the associated
> code, they were only added to support radiosity sampling at render time
> in 3.7. Otherwise, they serve no purpose.

To be precise, they were introduced to:

(a) provide an (optional) means to achieve full reproducibility of 
radiosity pretracing (otherwise thread scheduling will have a 
non-deterministic impact on the pretracing process and consequently on 
the final render result); and

(b) allow for adaptive radiosity pretrace, i.e. have a different number 
of pretrace steps for each render block depending on earlier pretrace 
step results

So even for radiosity renders those lists aren't strictly necessary (a 
bit of care must be taken though when removing them).

Post a reply to this message