Um, where did you spot that? As far as I’m aware, we don’t 
And how do you see the adaptive feature future Lukas? 
Ehm well i saw adaptive here a few times:
So its for something else ?.
Ps i just wanted to see how the cycles netrender would work, as i got to do a large render next week(s). But for the moment i think i stay with the youtube method. So after your bcon2017 presentation on youtube I was wondered what the benefit would be if it happens whitin the cycles so i looked at the git code/build
Wow, waiting for adaptive sampling with a lot of enthusiasm, it´s going to be another leap in rendering speed, I remember the difference when it was included in Corona, for a lot of situations it was awesome
Testing new version of this patch (Linux):
https://developer.blender.org/D2056
victor_cpu.blend default scene (without using Simplify otions) fits now in my 4GB vRAM (GTX 960)!
While scene render the total system vRAM is approximately 3.9GB, Blender takes 3.5GB of vRAM and approximately 8GB of RAM from 16GB total RAM.
You are amazing Brecht! Hopefully you can find a solution for that slowness with denoiser you mentioned 
Thanks to Stefan Werner too!
Hey Brecht and all,
Last night I spent a few hours rendering with the combined CPU/GPU feature that just got into master and here is what I found:
• I struggled a lot with tile size until I found that it’s now inverted for GPUs. So, a time size of 16 is now the fastest and a tile size of 128-256-etc. get’s slower and slower. Just like CPU. This is good news but quite baffling at first. It’s so contrary to how I understand GPU’s to work.
Even setting the tile size to 32 or 64 causes noticeable slowdowns.
I should point out that my scene is a perfect test case for this: a character with hair. Here’s why: if you have a larger tile size, there’s a high chance that a large portion of the hair will get rendered by a single CPU bucket. the rest of the buckets are moving along happily but this one bucket just sits there crunching away… By setting the tile size to 16 it ensures that no single bucket, CPU or GPU, gets to much work than it can handle.
What really surprised me was how this is now the case even when rendering with GPU only. I still get faster rendering with tiles size of 16!
I know this is better for rendering along side CPU but I still can’t seem to shake the feeling of loss. I used to love watching those huge tiles render great swaths of image in seconds. But, that’s life I guess. 
• Many times while rendering single frames I get this kind of stuttering, quick start/stop movement of the buckets. As if there was something happening behind the scenes like a memory allocation or something. It was happening during the rendering of my background pass which is just a soft white sweep. most of the time it just tears through it like nothing. But sometimes is goes hard and fast, then pauses for a few milliseconds then goes, then passes, then goes, etc.
I haven’t found a repeatable test case though so I have no idea what’s really going on. It definitely never happens when I render animation. So, that’s good.
• Rendering in the viewport continues while rendering with F12. This is particularly annoying and causes me to constantly have to hit the pause button on the viewport render while I test a frame. I don’t know if this is caused by the CPU/GPU commit but it’s a real inconvenience.
In fact, I just thought of something. I need to test it but the stuttering could have been caused by rendering in the viewport and F12 rendering at the same time! I’ll check it later.
• REQUST: Could we draw the bucket brackets in different colors for CPU and GPU? Like, GPU orange and CPU green? It would help determining which device is the cause of slower renders.
@Brecht: THANK YOU SO MUCH!
- 1 from me
That’s something I always wondered myself. Why can’t we tell which GPU is rendering faster? I got two 980Ti cards and one of them is always faster but I can’t tell which one. Maybe there is some way to tell but this will always be a nice touch to have.
+1
Actually, I know its the overclocked 
one but it would be great to have a visual feedback, I think.
I quote the @Indy_logic request . It’s useful to debug scene and I think it will be more useful when we’ll have a distribuited rendering.
Sorry to mention Vray but it has a render elements that color the buckets and write it the name of the PC is rendering that bucket.
These is useful when the render slaves render buckets differently from the others.
Obviously when you have just one PC you can only debug if the slow rendered bucket it’s due to CPU or GPU rendering.
The much awaited bevel shader is now in master.
https://lists.blender.org/pipermail/bf-blender-cvs/2017-November/101719.html
The official thread for this (in General Discussion) has all the info one needs to know (no need to repeat it here). It also appears to lay the groundwork for AO color/dirt/worn edges shading.
Absolutely awesome. My mechanical stuff turns to garbage if I pre-fillet/pre-bevel stuff prior to export, and even without it I get garbage enough output that requires too much cleaning up for bevel modifiers to work.
The denoiser is really slow when using low tile sizes though (like 16x16). This really screws over GPU+CPU renders too because if you use 16x16 tiles the denoising makes things slow, if you use auto tile size the tiles rendered on the CPU are really slow. For me auto tile size with just the GPU is faster even than GPU+CPU when using the denoiser.
you’re free to use what you choose denoiser will evolve too - is only it’s first official iteration
Yep, working on it.
I found a way to improve it quite significantly, for the BMW scene at 100spp it now takes 17sec at 16x16 and 9sec at 128x128 compared to 48sec at 16x16 and 9sec at 128x128 in the current master. Still not good, but it’s an improvement at least. I’ll clean it up and commit tomorrow.
Couldn´t we have an after-render denoise with a different tile size for denoising?
@lukasstockner97. Awesome! thanks 
@Cyaoeu. Anyway, you try on scenes containing some materials that are heavy for GPU:
You should get good render times even using denoiser, unless your CPU is really much slower than your GPU.
Cool, thanks for the great work! 
My CPU is pretty slow I guess (i7 2600K), my GPU is a GTX1070. I did some render tests with that file, my results were:
GPU 256x256 02:01.04
GPU 16x16 03:45.41
GPU 64x64 02:28.33
GPU+CPU 16x16 02:30.18
GPU+CPU 64x64 01:57.44 (last denoising steps on CPU really slow)
Note that this was with a master build (3f614cd) and not official. I noticed an interesting thing where the CPU got stuck a bit calculating the denoising with higher tile numbers, so in the end it would say 1 second remaining but it took 10 seconds. Anyway you’re right, with a scene like this GPU+CPU was slightly faster.
Ok, I can see. Let’s wait for those Lukas improvements then…
By the way, we still do not have your CPU in Benchmark list
(For official Blender 2.79 release)
I understand that it requires 3D data