Under 2.8 yes, and not only related to E-cycles.
Got a trick to fix this using an operator looking for output of a background session actually rendering and restart render from last known saved frame when bg session crash.
It does freeze your main session until full render done.
Setup your render in main session, including start / end frame, engine and output path, then save your file.
Thanks, I may need to try that! Iām never away from my desk for so long that this is anything more than annoying, and of course doing image sequences makes this even less of an issue, since you can pick up right where it left offā¦ but yeah, this sounds pretty cool and I should try it. Thanks again!
So guys, when editing HKEY in RegEdit to add TdrDelay, we use a DWORD (32-bit) even if we have 64-bit Win10Pro, and not a QWORD (64-bit), right? Please advise.
For 64 bit Windows
Select QWORD (64-bit) value.
Type TdrDelay as the Name and click Enter.
Double-click TdrDelay and add 8 for the Value data and clickOK.
A first version of the may update beta for 2.8x on windows is available. Itās more than 10% faster in most cases and uses around 20-30% less memory in my test.
On the 2080 TI, render time for BMW went from 27,3sec on april update to 23,8s with may update = 1.15x faster than previous E-Cycles. Memory usage went from 1483MB compared to 1927 MB on April update or latest buildbots. The memory usage reported by Blender is not exact, if you want to see the real saving, you can monitor it with MSI Afterburner for example.
Itās available at the bottom of the page and is based on latest master so you have all the nice UI improvements and bug fixes.
Dāoh! Still crashes on png sequences (average 10 seconds per frame - w/ three 980Ti), using latest (todayās) E-Cycles and adding TdrDelay of 40. Almost made it thoughā¦ with 219 frames done of 240. Can anyone shed some light on the discrepancy between bliblubiās suggestion of doing 32-bit DWORD HKey for 64-bit OS (as opposed to 64-bit QWORD HKey), and the info that is given on that page two posts up? This is perplexing. I just want to make 100% sure I am trying everything. I have a lot of crap to render in the coming daysā¦
Have you ticked āKeep User Interfaceā and āLock Interfaceā in the Render top bar then minimized Blender while rendering? You probably already know to do that but give it a shot if not! Or render from command line. The former has stabilized a bunch of animation renders for me.
Hey Mathieu!
Thank you for developing E-Cycles. Thank you for the update. I mainly use an AMD Vega 64, and for i know, OpenCL is not as optimized as CUDA in E-Cycles yet, i just wanted to let you know, that my OpenCL viewport render is not very stable, while the final render works well and pretty fast. Are you btw planning to implement rendering on Nvidia and AMD GPUs at the same time, like in LuxCore or ProRender for example?
Thank you so much for the great improvements of Cyclesrender.
Cheers, Johannes
I already have a patch to allow rendering with AMD + NVidia GPUs and CPU at the same time. But If I make it available, that will be without official support, as a beta. The reason beeing that their are still slight differences of how OpenCL and CUDA render, which can make tiles visible in some cases.
On top of that, OpenCL still doesnāt support rendering with small tiles efficiently. For that, the BF planned to allow GPUs to render many tiles at once, but as far as I know, Jeroen Bakker is now working on other things than OpenCL, so it may take time. Until the planned work is done, you will have to choose big tile size (at least 128x128), which will prevent using CPU in fact and slow things because their will always be one GPU waiting a long time for the last tile to be rendered. So it will only be beneficial for long renders, where the seconds waiting for the last tile are small compared to the overall render time.
After the May update is stable, Iāll make a beta build with it so that you can try by yourself.
Cheers, Mat
Iām planning to add it to all versions indeed, but in the current state, itās only benefiting the CPU renders as far as my test showed, most users report similar results (compared to E-Cyclesās sampler).
Iām working on making it faster on GPU and already managed to get good speedups, making it faster than E-Cyclesās sampler in some cases. When itās faster in every case or at least 90% of them, Iāll add it in official releases.
A favor to ask as student from you Coding Blender Course, please?
A week ago I started working on this same thing. I have initial support for CPU + Cuda + OpenCL rendering at same time. I can see and select all CPU , Cuda and OpenCL devices in user preferences but can only render with CPU and Cuda devices. I can select the OpenCL as well but those AMD devices donāt render.
I can play with the source code to be able to select and render with OpenCL and CPU but then the problem is inverted because now my Cuda devices donāt render.
Would it be possible for me to have a copy of your diff?, or maybe you can add it to your coding Blender course so that I can learn to do this properly? Iām really close, just missing something and Iām not sure what it is. New area of code for me.
Iām not worried about render artifacts because I may have a way to avoid them but not 100% sure till I can get it working with all devices for true test.
Thank you for everything you do and please let me know if it is possible.