Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crand feature is not thread safe in any >=3.7 version. #353

Open
wfpokorny opened this issue Apr 4, 2018 · 1 comment
Open

crand feature is not thread safe in any >=3.7 version. #353

wfpokorny opened this issue Apr 4, 2018 · 1 comment
Labels
artefact results in artefacts, i.e. render output that looks broken

Comments

@wfpokorny
Copy link
Contributor

Summary

The crand finish block feature is not thread safe. Scenes using crand and rendered with multiple CPU threads show differences from one render to the next due the use of crand alone.

See newsgroup thread at:

http://news.povray.org/povray.bugreports/thread/%3C5aa13810%241%40news.povray.org%3E/

Environment

Any CPU with multiple threads and all versions of POV-Ray >= v370.

Steps to Reproduce

Using the mist.pov sample scene shipped with POV-Ray:

povray mist.pov
(move the mist.png file to say mistA.png)
povray mist.pov
(compare mistA.png to mist.png with software able to detect or show differences)

Expected Behavior

A Scene using crand and should not change render to render given no other change.

Actual Behavior

See blotchy / blockish differences render to render.

Workaround

Use command line option +wt1 or ini file setting Work_Threads=1 whenever it is important a scene using crand render identically render to render.

Suggested Solution

For a suggested coding fix see the newsgroup thread for an idea from clipka :

http://news.povray.org/povray.bugreports/thread/%3C5aa13810%241%40news.povray.org%3E/

@wfpokorny
Copy link
Contributor Author

In scene testing I almost always run with no AA as it usually covers up issues, but still use -j. Further where scenes have area lights I typically remove jitter to get better comparisons. Lastly I render with one thread (+wt1).

Recently, I ran down a reason (see pull #358) the area_light jitter was sometimes causing differences even with +wt1. Understanding that issue, I've been running area light scenes with jitter and still with +wt1. Despite wording in the docs which to me imply complete render to render jitter randomness, I am seeing very reliable render to render results so long as I use a single thread.

Seeing this behavior with area_lights, I played with +am1 and +am2 - with a high +a0.6 bail out so the AA doesn't bury any jitter differences. Again, it seems like so long as one thread is used, multiple renders of identical scenes match.

So, looks to me like we have an AA/area_light jitter state similar to crand - for which we opened this issue with the thought results could be made consistent rendering with multiple threads. Seems like a good idea to extend any updated behavior to jitter too if able.

Making this comment and attaching a small test scene so whomever eventually takes a look at this crand issue can consider the AA(am1,am2) and area_light jitter situations too.

AreaLightJitter.pov.txt

@c-lipka c-lipka added the artefact results in artefacts, i.e. render output that looks broken label Jun 11, 2021
@c-lipka c-lipka added this to Triage in v4.0 Bugfixing via automation Jun 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
artefact results in artefacts, i.e. render output that looks broken
Projects
Development

No branches or pull requests

2 participants