improve parallel scalability about pbrt-v3 HOT 2 CLOSED

Hi Matt,

why did you write "not impressive" for path tracing etc.? I think 1.9 is pretty decent given other factors like memory traffic, job distribution etc..

The issue with SPPM resembles my own scalability benchmarks with Mitsuba. A better way to parallelize things would be to use the Knaus & Zwicker-style iterations where each photon map pass uses a globally uniform photon radius. This removes some interdependences so that each thread can do its own photon map pass. Maybe something for v4? (with things going like they are now, parallelism should be an even bigger deal a few years down the road)

Thanks,
Wenzel

from pbrt-v3.

Commit 74cab9e, which I'd hoped would help a bit with this, barely moved the needle. SPPM grid construction is now 1.98x faster with 16 cores than 1 core, which is an improvement from the 1.40x before, but there is still a ways to go!

@wjakob I dunno, maybe this is reasonable, but I feel like it could be better. The data is almost entirely read-only, there's a lot of compute and a lot of independent jobs, etc. (Or, coming at it from a different way, none has yet carefully ran it through a profiler to look for unexpected false sharing or other things that can meaningfully degrade scalability, so it's likely there are other unknown issues that could be tuned up...)

from pbrt-v3.