I just posted the new patch version to D808: The UI is updated, 2 parameters are gone, the default stopping threshold is 1 and IMO it’s way cleaner.
If you build Cycles with the Debug Passes enabled, you can now see the sample number, variance and importance.
Regarding builds: I’ll do them tomorrow, setting up a Windows build system with CUDA etc. is harder than I thought.
I downloaded the cubins and put them in place of the original ones (2.72)
nothing happened in the UI (using GPU here)
what am i missing?
thanks Lukas 
Hi lsscpp, I had an error in reasoning! :o
The kernel alone make no sense, you need really a complete build.
I build Blender Linux 64 with static linking and reduced features, no ffmpeg, OSL and so forth.
Can you try it? It is not the actual patch, it is from Friday.
If it work for you I rebuild it with the patch from today.
Cheers, mib
EDIT: I think there are still some missing libs, grrr.
I really would like to share my builds but it is really hard to build Blender static. 
Thanks for the effort mib!
Anyway at the moment it’s easier for me to access to windows workstations, so i guess i’ll wait for Lukas’ builds
edit: oh by the way, other can find your build useful of course, so… good job anyway! 
@lukasstockner97, hi, tested new patch and work fine.
The new UI panel settings are really easy to handle now.
Within a few minutes I got same render performance as before with hours of trial-and-error technique.
Thanks Lukas, very nice.
@lsscpp, thanks. 
Cheers, mib
Sounds like it will be a real treat to use once the Win64 builds come out, this means that the concerns of it requiring too much trial and error to use will also be resolved.
Patiently waiting for the build planned for today 
So this is the Win64 build, created with MSVC 2013. CUDA and OceanSim are enabled, but Cycles debug passes aren’t, so the new passes won’t be available. I hope all DLLs are present, if not, you can probably copy them from the 2.72 build of buildbot packages.
Considering Mib2berlin’s experience, I don’t think the debug passes will be necessary to get good results.
Thanks.
Okay, first impressions are really good.
Compared to the patch in July, the adaptive sampling seems to now be much better about converging the brighter areas while still getting to the more indirectly-sampled regions (the latter had a tendency to be oversampled in the last version).
And yes, I did have to copy a few .dll’s from the buildbot build I downloaded today, nothing you couldn’t stick in the .zip archive though (so to avoid complaints from those who don’t know what to do).
First impressions from me is that it works quite well, but doesn’t handle when there are many lights in the scene with MIS.
Would be great to see this in trunk
I just did a few test, definitely huge improvement in speed. Here are some numbers:
Character with no background: before 54 seconds, after 27 seconds
Character with background: before 8 minutes 29 seconds, after 3 minutes 22 seconds
Car: before 2 minutes 30 seconds, after 1 minute 40 seconds
As you can see there’s a big improvement in render time. It might need some extra work but for me it works great. Looking forward to see this feature on the master. This might be one of the best things that happened to Cycles.
Kudos and thanks.
For reference, it would seem that choosing the Sobol distribution with adaptive sampling will give far superior results compared to Multi-Jitter. It’s the same with small-ish (but not super tiny) tile sizes compared to large tiles.
Just to note if you’re looking for better results.
many noise in dark areas
I did a quick test as well and I’m impressed. I may keep this around just for rendering.
Scene has car with paint materials and buildings with glossy windows, a char with hair particle system and a particle system with a few trees on the landscape. Some other low poly cars and trucks with car pain material.
normally I render this at 100 samples because it is for a video sequence but I bumped up the samples for the test.
Render size 1280/720, samples 576
cpu tile size 80/90
Cpu adaptive Sample and distro disabled 5:29.56
Cpu adaptive Sample and distro enabled 2:16.11
GPU Tile size 320/360
GPU adaptive Sample and distro disabled 2:38.04
GPU adaptive Sample and distro enabled 1:22.05
Great work so far.
specs in sig
@Ivan K
You don’t have any materials applied to the two planes. I’m not sure what cycles is doing in this default condition. I added a diffuse materal color black to both and rendered without any noise.
It seems that without a material applied blender is using a white diffuse material with roughness of 2. I was able to duplicate your render with that material applied.
I also tried your test file in blender 2.72 standard build and it renders the same as your test.
Which in my opinion means the test is invalid.
Edited for spelling and to correct the material info.
Reduce the error to like 0.2 instead of 1
There is no noise in his render. If you render his test file in Blender 2.72 standard build it does the same thing.
I did some testing before on low light settings and what not… to get it looking clean i did have to reduce the tolerance ot around 0.2
but then there will be a lot of samples in the bright area, but it is incorrect
Hmm. There seems to be something I’m missing. It doesn’t work for me at all. Turning Adaptive sampling on and off yields the exact same image and the same render time. I can’t even find an option for adaptive stopping. Supported vs experimental kernel doesn’t seem to matter. Neither does CPU vs GPU.