Hello Mathieu
Just to confirm last version (190617) works as expected on Debian 9 with i7-8700 and GTX1050 2G…but you know that already (o;
1 Like
Thank you, it’s always good to confirm.
Thanks for the further clarification bliblubli. I’ve been talking things over with the team in my spare time. It’s been a busy week. I do have a few more important clarification questions still to ask as I gain insight from the team and further reading research.
I’m looking forward to your thoughts on the few more questions I have that I’m taking time to make sure are informed and well thought out.
Thanks.
1 Like
You’re welcome, but what about also clarifying on your side? You came up with a ready Idea of what happened and throw that in the wild without any check. I would happily accept excuses about the method if you think like me and most democratic states that people are innocent until proved otherwise.
3 Likes
And for everybody here who thing he is the guardian of what is good or bad and can judge other because he think he is better. We are only a few people working hard for not much in return compared to many people of similar skills in the closed source world (see here, thanks @ambi for the link). So I think a good start to make the best out of our limited resources would be that we take care of each other, even if we sometime think differently.
3 Likes
I would definitely buy that, some sort of auto unwrap?
Yes, it’s kind of auto unwrapping that adapts to your edits in real time. I’ll try to make a simple release soon.
5 Likes
E-Cycles vs Octane with KHAOS! explosion simulator in Blender…just crazy!
2 Likes
Hmm…odd…when I compare render times with Ecycles 190606 between a RTX2080 and RTX2080Ti I get:
RTX2080: 266 seconds
RTX2080Ti: 230 seconds
So not even 20% faster…
Also tried master branch…same figures…
OctaneBench4.0c shows:
RTX2080 score: 218
RTX2080Ti score: 303
Which are the average values shown on the Otoy results page…
As I don’t have the same cards to compare, it’s hard to tell if the 2080 is too slow in Octane or the 2080Ti too slow in Cycles/E-Cycles. The scene chosen can have a great influence on how a card compares to another. The Boostclock test above show the first scene gives 1.33x faster rendering on the 2080Ti so near OctaneBench with 1.39x factor. But the second scene from BoostClock only show a 1.26x faster rendering with the same hardware, same programs, same OS. In your case it’s 1.16x, so it sounds very low.
- Did you render each time with only one GPU and was the denoiser on?
- Could you please try with the 20190516 build.
- How is the factor on the BMW scene https://download.blender.org/demo/test/BMW27_2.blend.zip
Hi, I have not much time but read Opensuse user has segfault so I test latest version quickly and it work fine with denoise on my laptop:
E_cycles_2.8_v20190617_lin
Opensuse Tumbleweed x86_64
CPU i7-3520M 8 GB
GPU Intel HD4000
xf86-video-intel 2.99.917-6.1
KDE Plasma 5.54.5.11
I will test on my workstation with i5 GTX 760 in a few hours.
Cheers, mib
1 Like
Really seems to depend on the scene on not on Cuda cores count:
BMW Master Branch:
RTX2080 52.26
RTX2080TI 38.82 +34.6%
E-cycles 190606:
RTX2080 33.77
RTX2080TI 25.85 +30.6%
Interesting…in this scene RTX2080 is faster as a Ti on the master branch (o;
Also to note that the speed increase for the Ti is lower. Even when deducting the 1 seconds initialization time before start of rendering…
BTW: Does gumroad send an email when a new version is published?
Thanks Mib,
it’s a bug with TBB and Ryzen processors on Linux distros with GlibC < 2.27. Intel processors or Ryzen on Windows/Mac/recent Linux work as expected.
Hi,
that’s what I thought. Some scene will use the cache more, ensuring the CUDA cores are fed well with work, some other scene will have more random memory access and will need the slower GDDR more, making the benefit of having more cores less noticeable.
Also GPUs need a certain sample count to have enough work. CUDA GPUs start to be well occupied with more than 300spp most of the time.
I’ll start to update the benchmark files to get better render times. Under 30 seconds, a lot of factors can come into play that start to have a significant impact on the final calculated percentage. In your case, 1 second pre processing and 1 sec compositing and it already increases the overall render time by 8%. On slower CPU and/or Windows, it has even more impact and often goes over 10%.
Yes, a 2080+E-Cycles is faster than a 2080Ti, so you can get faster than a 2080Ti for 700€. If I would do 50/50 with the E-Cycles users on the money they spare, I would be rich 
I generally now send E-Mails only for big monthly updates. For weekly updates, they most of the time only contain bug fixes, so I only post here when the builds are ready.
Thanks for the clear explanation 
I will definitively get the yearly subscription when this monthly runs out (o;
Hmm…bugger is that I always need to connect the monitor to PCIe slot 1 where I want a cheap GTX, so no joy running two TIs on x16 slots…though x8 should not be that much of an impact…
I work on huges environments, I only care about performances for ultra high polys scenes and border line vram load. Any info about performances ?
Someone is working on making optimizations to the BVH code.
3 Likes
Just a heads up for anyone interested - Barista can’t currently use the Compositor so it can’t take advantage of OIDN. I think they are going to look into adding support for it though!
Hi,
So i got this interesting thing when rendering sss (E-cycles sss enabled)
The First is correct (Using Christensen_Burlen) the second (Using RandomWalk has the strange tint to it.
Christensen_Burlen
VS
RandomWalk
