I don't recall reading there is a rule not to reopen tasks from others when they are still valid.

Please don't re-open tickets, especially if they are not yours to begin with.

Reopening this to raise awareness after 3 months as many many materials rely on NodeGroups with inputs.

Score! thanks for the quick test!

Thank you, this issue seems to be resolved as of 76f640c27d8.

we have recently updated osl/llvm, is this still an issue? @Tim (ptim) can you check with a nightly build?

I can also confirm the problem.

ahh, hybrid is the blocky stuff :)

CPU and GPU are rendering different results. Here's the comparison.

OK, my bad.
Now I also noticed the difference CPU/GPU (no denoiser) Here is what I get [not getting the blocky stuff though...]:

It seems to be an GPU issue. Here's the CPU result. No artifacts.

Also happens under Linux Mint with a GTX 780 and with a Xeon / GTX 1080ti.

Here's again the scene I used for the above video with the settings (1024 samples). The former upload was an older scene with different settings. Just to get sure.

No. It also happens on my XPS with GTX 1050.

Maybe an issue by the AMD Threadripper and/or GTX 1080Ti?

Yes, it's not a Denoiser issue. My above rendering isn't using the Denoiser and a sampling rate of 1024. I have an older video of the same scenes without artifacts but I can't say what build I used for it.

I gave it a closer look and my initial thought also was that the denoiser freaks out. When you disable the denoiser you can see that there's a lot of noise in the rendered image (where it would be a miracle if any denoiser could properly resolve that BTW). But: it's not the denoiser's fault because the flickering artifacts are already present in the "raw" render!
I could reduce the whole scene to only 3 Lego bricks (around the sink) which still gave me the error. The artifacts don't appear if I override all materials with a simple Principled shader. So it looks like the (quite complex) materials (or at least one of them) is faulty or maybe some bump or normal shader doesn't play nicely with a scaling of 0.001 the whole scene is at. Plus I think that setting the render camera limits to 1mm - 2km doesn't help numerical precision either.
It might also be a combination of things that cause this, but the Denoiser is innocent.

here is what I get with the file from the report

Seems like Denoiser artifacts (which can have a hard time in animated DOF/MBlur scenarios), so I wasnt sure if there is a bug involved here...
But as these are also apparent in 'in focus' areas I started rendering (still doing) and I'm actually having a hard time reproducing these (linux, 2.79 master build from buildbot, GPU rendering, 970m, 396.45 drivers, cuda 9.2)...
(will post the cropped border render sequence [kitchen sink area] in a bit)

https://youtu.be/IjF6TEcvgoA

Oh, damn, I've forgot about new Displacement input behaviour!

Interesting... I've removed all linked materials and geometry stays where it is... But when I make them local, there is still offset.

I don't see any difference between 2.79b and latest master rendering this file. But it is also giving me errors about missing libraries so maybe not all the .blend files needed to reproduce the problem were included?

Change tileable option name to periodic. This matches name used in Gabor patch and is more accurate in how the option works relative to scale.

Added patches for seamless Voronoi and Gabor.
https://developer.blender.org/D3743
https://developer.blender.org/D3495

• Rewrite patch with Cycles, Eeevee(GLSL) and OSL support
• Incorporates anisotropic modes from OSL implementation
• Supports periodic/seamless textures (if scaling is set to whole numbers)
• Exposes variables to control impulses, bandwidth, frequency, rotation, weight (amplitude), phase and variation (randomness)
• Seed is exposed for varying small periodic textures
• Supports additional kernel shapes
• Removed multiple calls to RNG and uses a single call per sample, in my tests this seemed ok
• Direction input for Anisotropic mode (possible bug in Eevee as it needs to be connected to work correctly)

In T56939#538694, @Bastien Montagne (mont29) wrote:

That does not really sounds like a bug to me, but will let @Brecht Van Lommel (brecht) decide here.

Done. That was actually my intention but used the wrong branch.

That does not really sounds like a bug to me, but will let @Brecht Van Lommel (brecht) decide here.

Thanks for the bug fix... Any chance we can get it applied to the master branch aswell?

That seems reasonable, we don't have to use the OSL builtin one.