Thanks. It works fine in a daily build
This issue should be fixed in latest builds already. So test blender from builder.blender.org and see if the issue happens there.
Sun, Nov 19
Please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.
Tue, Nov 14
Blender-fix solved the issue
Mon, Nov 13
I can confirm this fix works!
Thanks a lot for solving this problem.
Setting priority to incomplete since we are awaiting more feedback now.
Managed to redo system becoming frozen at some point during synchronization after BIOS update.
All our standard benchmark files survive. Performance is good. We don't have time now to restore or test production files.
It would go much faster if you would share a case, or tell us how to produce a case that's slow? Use one of the benchmark files, duplicate stuff or so?
So nice!, now burn the CPU with some crazy scenes to find out if there is something wrong with scene buffering.
We've just received a beefy system with Threadripper! Testing started :)
Sat, Nov 11
Additional information was provided.
Setting to Needs Triage.
Fri, Nov 3
dual E5 2660 v3's (2.6 ghz) (40 Threads) Z10PE D8 WS, 96 gigs of ram win 7 x64 GTX 970 Windows 7,
Please follow our submission template and guidelines, also read these tips about bug reports, and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.
Tue, Oct 31
Sun, Oct 29
I've several systems at home, and noticed that Cycles crashed when I had the Denoise feature enabled on my Intel Atom laptop.
Oct 24 2017
Right, I'd be happy to debug it at bconf. Remote desktop access would work as well at some other time.
AMD was meant to send us (Blender Institute) a threadripper in July already. I reminded them again what happens with it.
Oct 21 2017
Oct 20 2017
Right, the fixed 0.25 roughness is definitely a hack, hopefully we can get rid of that too.
Maybe also the fixed roughness of 0.25 for the G term can cause some issues. Disney didn't really say in their paper from 2012 what the purpose of this hack was, but only that it's "found to be plausible and artistically pleasing". I will try at first to change only the D term to GGX without changing the G term (which means keeping the 0.25 roughness here) and look if this causes more problems and if so, I think we should go with having a consistent roughness throughout the whole clearcoat calculation. By doing so, we wouldn't need to have a distinction between clearcoat and non-clearcoat in the Microfacet BSDF evaluation (except for the sample weight) anymore.
@Brecht Van Lommel (brecht), yes, I see this like you do. I don't think that we get a real benefit out of the GTR1 distribution. The difference (especially because clearcoat is only applied with a pre-factor of 0.25) should be pretty low and can thus be neglected. For me it seems ok to switch to GGX, but I will at first try to compare both versions today before adding a patch.
Oct 18 2017
@Pascal Schön (VanCantus), the root of the issue here seems tricky to solve.
Oct 17 2017
@Brecht Van Lommel (brecht), we don't have threadripper at the studio, only Ryzen 7 1800X.
@Sergey Sharybin (sergey), is there a machine with a CPU like this in the Blender Institute?
The first time i tried to render the scene was unpacked. After hanging for hours i started using all the benchmark files on the blender website and comparing this with my intel system. On this point i saw a significant difference between the threadripper and my intel sytem. Not on the small ones like the BMW, classroom, but the production benchmark and my own scenes. In my opinion most of the threadripper tests where done on these scenes, and not large scale RAM scenes.
Oct 16 2017
Does it work if you unpack the textures first?
@rob (blenderpedia) Okay, gotcha.
@Brecht Van Lommel (brecht) I'm not sure he did the OpenMP test as you described.
The video showed him changing threads in the UI as opposed to a command line command. Is that the same?
Rob, can you verify that you ran this in command line?
Intresting result when doing a blender internal benchmark test. I used an 11 GB ram scene on my 4770K and threadripper workstations.
Oct 15 2017
@Joel Godin (FloridaJo), the GPU is not involved in the synchronizing objects stage, so I doubt it's causing issues here.
It doesn't look like it's the CPU.
You may want to see if it is a GPU bottleneck.
GPUview is the tool for that, a description of it is here;
Which parts of the render are slow? The video shows just the synchronizing objects stage, is BVH build slow too, and path tracing?
I created a video including microsoft Process Explorer.
Can you go to this page and follow the instructions for installing the Microsoft Process Explorer
to better show the threads running during that process?