povray
povray copied to clipboard
Subsurface thread safety issue.
Summary
Where the number of CPU threads greater than one, subsurface render sub-block results are not stable render to render. Also see newsgroup thread:
http://news.povray.org/povray.binaries.images/message/%3C5a941687%241%40news.povray.org%3E/#%3C5a941687%241%40news.povray.org%3E
Environment
Ubuntu 16.04. Master branch as of commit 9c67174 Sat Jan 6 11:58:42 2018 +0100 "Merge branch 'release/v3.8.0'". Personal compile. Fails in a similar manner in the 3.7.0 stable branch so the issue existed in the original feature release. Intel i3. g++ -std=gnu++11 5.4.0 @ x86_64-pc-linux-gnu.
Steps to Reproduce
Using the subsurface.pov scene shipped with POV-Ray and the command:
povray -j -d -c -p +wt4 subsurface.pov
changing only the number of threads each time.
Expected Behavior
All image outputs should be the same no matter the number of threads used.
Actual Behavior
Results change by block when threads used > 1. See Output section below.
Render Settings
povray -j -d -c -p +wt4 subsurface.pov
Scene
Use the sample subsurgace.pov scene shipped with the distribution.
Output
See the attached image. Three columns left to right with images in the first two rows rendered with 1, 2 and 4 threads. The bottom row is an 8x multiple of the image pixel differences.
I've not seen any differences between single thread renders in a half dozen runs. Always some difference in multi-thread runs, but the signature is interesting in that POV-Ray seems to match on some of the sub blocks. More often ones at the top match, but I've seen render-image pairs with matching blocks better than half way down into the image.
Workaround
If stability render to render is needed, must today use +wt1 on the command line or Work_Threads=1 in any .ini file created for scenes using the subsurface feature.
Suggested Solution
Debug the thread safety issue.
Quick note for whomever follows up here. I remembered a similar thread-block oriented visual issue in the closed FlySpray bug : http://bugs.povray.org/task/17 related to the shadow cache mechanism and threads >1. I tried a compile disabling the shadow cache mechanism as a shot in the dark at this issue and saw no change.