Blender Freeze OpenCL Render

[Dade]

Is there a recommended version of the nVidia drivers? Or is it always best to have the latest?

It is hard to say, they seem the result of a random process

[kintuX]

Is there a recommended version of the nVidia drivers? Or is it always best to have the latest?
I have just tried to render the scene: first it crashed blender some times, then I switched materials as suggested by dobe and this time I had BSOD on Windows 10.
I have rather old drivers, as they were giving not too many problems...

Try this first...

Disable the visibility map...

PS.
yesterday i updated GPU drivers also, 39x seems stable for now (& yes, there were some bad issues with 38x.xx gen).

[dobe]

I attached at this message the version "slow to compile but it works" of the pyluxcore.pyd. This one compile and run the above scene without problems

AND

Try this first...

Disable the visibility map...

works for me

[acasta69]

Thanks, the "slow to compile" version worked fine also here.
And I will try to disable the visibility map.

[Dade]

Thanks, the "slow to compile" version worked fine also here.
And I will try to disable the visibility map.

Try to compile from the very latest source this (https://github.com/LuxCoreRender/LuxCor ... 986a5eaf06) may explain the visibility map related crash. I reverted the latest sources to the "slow to compile" configuration too.

[acasta69]

Try to compile from the very latest source this (https://github.com/LuxCoreRender/LuxCor ... 986a5eaf06) may explain the visibility map related crash. I reverted the latest sources to the "slow to compile" configuration too.

Thanks Dade, I will try.

[jensverwiebe]

Problem is wit boost::atomics::atomic value_type.
On macOS it would not even compile.
In ComputeVisibility function the SLG_LOG in line 207 gets into probs while substituting the deduced template arguments.
Guess thats the underlaying prob, but compiles on linux and crashes @ runtime.

EDIT:
After the attempt to fix the deletes it now goes:

Code: Select all

[LuxCore][1.954] Visibility map done in 0.15 secs with 1000000 samples (6.71M samples/sec)
*** Error in `./bin/luxcoreui': free(): invalid next size (fast): 0x0000000009628f50 ***

EDIT2:
Still alternates with:

Code: Select all

*** Error in `./bin/luxcoreui': malloc(): memory corruption (fast): 0x0000000008544e60 ***

Race condition ?

[jensverwiebe]

Made a test with luxcoreui:

Code: Select all

diff --git a/src/slg/lights/envlightvisibility.cpp b/src/slg/lights/envlightvisibility.cpp
index 0b0f63f..45d5049 100644
--- a/src/slg/lights/envlightvisibility.cpp
+++ b/src/slg/lights/envlightvisibility.cpp
@@ -191,7 +191,7 @@ void EnvLightVisibility::ComputeVisibility(float *map) const {
        MetropolisSamplerSharedData sharedData;
        samplesDone = 0;
 
-       const u_int threadCount = boost::thread::hardware_concurrency();
+       const u_int threadCount = 1; // boost::thread::hardware_concurrency();
        vector<boost::thread *> threads(12, NULL);
        for (u_int i = 0; i < threadCount; ++i) {
                threads[i] = new boost::thread(&EnvLightVisibility::ComputeVisibilityThread,

Works fine and mapbuilding is fast enough with 1 thread:

Code: Select all

[LuxCore][1.410] Building visibility map of light source: __WORLD_BACKGROUND_LIGHT__
[LuxCore][1.471] Visibility map done in 0.06 secs with 1000000 samples (16.45M samples/sec)

4 threads:

Code: Select all

[LuxCore][1.393] Building visibility map of light source: __WORLD_BACKGROUND_LIGHT__
[LuxCore][1.498] Visibility map done in 0.10 secs with 1000000 samples (9.57M samples/sec)

Tested the boost function because:

unsigned hardware_concurrency();
Returns:
The number of hardware threads available on the current system (e.g. number of CPUs or cores or hyperthreading units), or 0 if this information is not available.

Code: Select all

diff --git a/src/slg/lights/envlightvisibility.cpp b/src/slg/lights/envlightvisibility.cpp
index 0b0f63f..78d0575 100644
--- a/src/slg/lights/envlightvisibility.cpp
+++ b/src/slg/lights/envlightvisibility.cpp
@@ -192,6 +192,7 @@ void EnvLightVisibility::ComputeVisibility(float *map) const {
        samplesDone = 0;
 
        const u_int threadCount = boost::thread::hardware_concurrency();
+       SLG_LOG("Available Threads: " << threadCount );
        vector<boost::thread *> threads(12, NULL);
        for (u_int i = 0; i < threadCount; ++i) {
                threads[i] = new boost::thread(&EnvLightVisibility::ComputeVisibilityThread,

Code: Select all

[LuxCore][1.536] Building visibility map of light source: __WORLD_BACKGROUND_LIGHT__
[LuxCore][1.536] Available Threads: 16

... and crashed.

Same test with Dobe's problem.blend from within blender ( pylux ):

Orig. code with logged hardware_concurrency() ( 16 threads, oddly does not crash ):

Code: Select all

[LuxCore][5.601] Building visibility map of light source: __WORLD_BACKGROUND_LIGHT__
[LuxCore][5.601] Available Threads: 16
[LuxCore][5.955] Visibility map done in 0.35 secs with 1000000 samples (2.83M samples/sec)

1 thread:

Code: Select all

[LuxCore][5.601] Building visibility map of light source: __WORLD_BACKGROUND_LIGHT__
[LuxCore][5.955] Visibility map done in 0.35 secs with 1000000 samples (2.83M samples/sec)

Atm. Looks as 1 thread is best option.

[Dade]

Have you looked at the code ?

Code: Select all

        vector<boost::thread *> threads(12, NULL);

For some (esoteric) reason I hard coded the number of my PC cores (it must have been a test). So it crashes for anyone with more than 12 hardware threads (6 cores + hyper-threading) and works for anyone with less or the same cores count. This explain why it was crashing only for few people.

Going to fix this problem.

[jensverwiebe]

Eeeeeek

Testing now: vector<boost::thread *> threads(threadCount, NULL);
..but expect slower building .

Edit:
Result:

Code: Select all

[LuxCore][1.486] Building visibility map of light source: __WORLD_BACKGROUND_LIGHT__
[LuxCore][1.632] Visibility map done in 0.15 secs with 1000000 samples (6.83M samples/sec)

Jens