It is hard to say, they seem the result of a random process
Blender Freeze OpenCL Render
Forum rules
Please upload a testscene that allows developers to reproduce the problem, and attach some images.
Please upload a testscene that allows developers to reproduce the problem, and attach some images.
Re: Blender Freeze OpenCL Render
Try this first...acasta69 wrote: ↑Sat Feb 17, 2018 1:53 pm 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...
PS.
yesterday i updated GPU drivers also, 39x seems stable for now (& yes, there were some bad issues with 38x.xx gen).
Re: Blender Freeze OpenCL Render
Thanks, the "slow to compile" version worked fine also here.
And I will try to disable the visibility map.
And I will try to disable the visibility map.
Re: Blender Freeze OpenCL Render
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.
Re: Blender Freeze OpenCL Render
Thanks Dade, I will try.Dade wrote: ↑Sat Feb 17, 2018 5:32 pm 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.
-
- Supporting Users
- Posts: 141
- Joined: Tue Jan 09, 2018 6:48 pm
Re: Blender Freeze OpenCL Render
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:
EDIT2:
Still alternates with:
Race condition ?
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 ***
Still alternates with:
Code: Select all
*** Error in `./bin/luxcoreui': malloc(): memory corruption (fast): 0x0000000008544e60 ***
-
- Supporting Users
- Posts: 141
- Joined: Tue Jan 09, 2018 6:48 pm
Re: Blender Freeze OpenCL Render
Made a test with luxcoreui:
Works fine and mapbuilding is fast enough with 1 thread:
4 threads:
Tested the boost function because:
... 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 ):
1 thread:
Atm. Looks as 1 thread is best option.
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,
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)
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)
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
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)
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)
Last edited by jensverwiebe on Sat Feb 17, 2018 11:07 pm, edited 1 time in total.
Re: Blender Freeze OpenCL Render
Have you looked at the code ?
Going to fix this problem.
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.jensverwiebe wrote: ↑Sat Feb 17, 2018 10:27 pmCode: Select all
vector<boost::thread *> threads(12, NULL);
Going to fix this problem.
-
- Supporting Users
- Posts: 141
- Joined: Tue Jan 09, 2018 6:48 pm
Re: Blender Freeze OpenCL Render
Eeeeeek
Testing now: vector<boost::thread *> threads(threadCount, NULL);
..but expect slower building .
Edit:
Result:
Jens
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