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.

@Brecht Van Lommel (brecht) I'm going to try and revisit this. From working on the Voronoi node I think that it would be better to implement this separately to the built in OSL gabor noise. This way it is much easier to keep Cycles, OSL and Eevee in sync. Can I get your view on this?

Fix tiling when color option is used.

Possible breaking changes in OSL 2.0 that breaks noise that uses quick_floor.
Replaced with OIIO::ifloor.
https://github.com/imageworks/OpenShadingLanguage/pull/912

In D2574#84917, @Brecht Van Lommel (brecht) wrote:

I'm not sure if the math is supposed to work out so that no normalize is needed, @Lukas Stockner (lukasstockner97)?

Just in case you need more examples, I could provide more .blend files.

It is the exact same, unresolved issue. Completely unfixed.

I'm not sure if the math is supposed to work out so that no normalize is needed, @Lukas Stockner (lukasstockner97)? But it seems fine to add an extra normalize if only for a bit better precision, since this code only runs when a correction is needed which is a small subset of pixels.

Okay, thank's for the info @Caetano (Caetano)! That's too bad that it's not a feature yet.

Sorry to have bothered you. I must have messed up my system somehow. (I have been trying to build Blender myself, but I kept getting errors regarding OIIO and LLVM amongst others, so maybe that has had something to do with it...) Made a fresh install of Linux and now everything works fine! Thanks for your attention.

Please attach a .blend and image file that has the problem. Maybe OpenImageIO has a problem loading particular file formats.

The issue was solved for an original author.

Uninstalled and reinstalled, now does not even open. Good job Devs, you have successfully destroyed what might have been good software.

This program is essentially unusable until they get around to fixing this. So basically this program will never be usable.

I have no idea why this has been marked as resolved. Still does not work.

Already discussed here:
https://devtalk.blender.org/t/how-does-cycles-handle-gpu-thread-priority-and-can-it-be-changed/1059/7

I’d bet that’s more like known limitation than bug, but will let you decide her, @Brecht Van Lommel (brecht).

@Dan Hickstein (danhickstein) Still not, apart from the workarounds proposed in Stackexchange. That said, I wonder if the Everything Nodes project can address this even though it's a Cycles feature.

I'm also interested in generating a volume based on an image sequence. It seems that a number of people are interested in this, with several questions over at the blender stackexchange relating to this:

Is it possible that this is missing a normalize() at the end? I'm seeng non-unit length normals being passed into the BSDFs now.
For example the classroom benchmark scene asserts with NaN pixels now.

In this case, perhaps @Brecht Van Lommel (brecht) can provide more detail about the normal calculations and if an equivalent is available from Cycles.

It’s not saved because there is no data at all (as can be checked with a viewer node), for both volume passes, when Save Buffer is enabled. @Brecht Van Lommel (brecht), guess that one is for you?

For OpenCL no extra work is needed, the kernels are compiled at runtime.

@Brecht Van Lommel (brecht) Yes, You are right. I am talking about standalone cysles renderer project.

I guess you built Cycles standalone yourself. Did you configure CMake to build CUDA binaries, and if so wat are the relevant CMake variables set to?

This is not quite what I remembered it to be, so I guess I should say a few things about the algorithm.

Same here

@Brecht Van Lommel (brecht) After I change units, I expect that I could re-add the default scene objects and that the render would be the same as the unchanged default scene. That isn't what happens. The most noticeable difference is that the Point Lamp strength has to be increased a lot; I would expect it's strength to be scaled to match it's larger size.

Thanks.

It's not resolved in aa844ad676d from today. The CUDA error still exists. Viewport works. First render after fresh load will just render CPU tiles but GPU tiles keep empty. Second try will give a CUDA error. I also had again a Blue Screen. But not everytime.