This is a main cause for errors, especially with less experienced users. The problem is that any Windows or nVidia drivers update can reset these values in the Registry :(
Allegorithmic had enough "bug" reports because of this issue and so they not only released a documentation on how to fix it but also added a check during the startup of Substance Painter that warns you in case your TdrDelay and TdrDdiDelay values were too low.

No crashes for me in latest 2.83 (e3f89237fecc). Tried duplicating Shader nodes and Compositor nodes.

Can confirm in 2.83 latest (e3f89237fecc)

Funny, yes. If I get rid of the Outliner I can actually do a "Full Copy" without instantly crashing Blender,. But as soon as I change the layout containing a Outliner again it crashes.

Update: Full Copy doesn't crash if the scene is completely empty, i.e. not containing any objects, camera or lights (or anything else).

Are there plans to also support OIDN? There are still lots of non-Optix systems out there and LuxCore is working nicely with OIDN viewport denoising.

Hi there!

If you scale up emitting geometry you get more light because it keeps its brightness (which makes total sense because otherwise you would have to know the total size of the emitting surface).
If you scale an area light it is normalized so that the total amount of emitted light stays the same. Like in real life, your lamp emits a certain amount of light, but if you change the size of the diffuser in front of it you don't get more light but softer / dimmer light.

For me this doesn't only happen with HDR lighting, but also with a simple point light and a Principled shader.

With "Manual" samples set to twice the horizontal resolution:

Here's a blend file that more clearly shows the problem (also based on a CC0 texture from HDRI Haven).
Just press F12 and see the fireflies, now switch the sampling to "Manual" (which I set to 2048 = twice the horizontal resolution of the environment map) and all is fine with the same amount of samples and no clamping needed.

I can confirm the subdiv level 5 crash with a simple cube on Linux Mint 19.2
Blender 2.82 e203f69bc3eb

I guess / hope this was already fixed by https://developer.blender.org/rB1e480840a2123a6b61e7aa3e6f7935b6654f9981

:) You're welcome. Thanks for taking care of this.

I just fired up my old and trusty Softimage 2015 because it had a very nice multi-select behaviour: If you select 2 or more objects with different attributes, it displayed an empty value for everything that wasn't set to the same value in all objects. If you now typed in a new value it set it to the same for all objects. BUT: if you entered something like "2+" it added 2 to all of the selected objects' property values. Very very nice. You could even enter expressions to e.g. randomize a value per object.

Here's your original material with a diffuse of HSV 0.5, 0.5, 1.0:

The setting is in the preferences now (where it belongs!):

In rBcd5c706303180effac32e09c13a286f730ad9777#246554, @Bastien Montagne (mont29) wrote:

Both issues should be fixed now, thanks for the heads up.

In rBcd5c706303180effac32e09c13a286f730ad9777#246496, @Bastien Montagne (mont29) wrote:

Hrmmpff… yeah, that parameter is new in py 3.7… I will use stdout one instead, that way older sys python can still be used here.

In rBcd5c706303180effac32e09c13a286f730ad9777#246482, @Bastien Montagne (mont29) wrote:

@Steffen Dünner (SteffenD) Which version of python?

I'm getting this (on Linux Mint 19.2):

vertexColor_blender_colorSet1.abc is also working fine in Houdini 17.5:

@Sybren A. Stüvel (sybren) : I just gave the very latest master ( 7f29fc7415a4 ) a quick try and now the normals are perfect for both Alembic im- and export. Much appreciated! Thanks!

@Sybren A. Stüvel (sybren) Great to hear! Thanks for your support!

I don't know if this helps, but I prepared some ABC files in Blender and Houdini which show that Blender currently ignores / destroys the custom normals both on import and on export.
I have an original car hood geometry that looks perfect in Blender. I exported it as an FBX and import it into Houdini. Normals are still OK. Then I export it as an Alembic from Houdini. The normals are still OK, but they aren't imported correctly in Blender.
If I export the geometry with the correct normals as an Alembic from Blender, the normals are being garbled during export. If I import it in Houdini it looks like this:

Awesome! 👍

OK, did a complete rebuild from scratch and vc16 libs: same crash
And just a few minutes ago a fresh build from the Buildbot came out ( 5a144c797a3b ) and it also crashes on 2 different workstations (the one in the description above and a Threadripper 1950x machine with a GTX 1080, both running Win10 x64).

Thanks for having a look at it. Just in case it helps, this is what I get if I start and crash Blender from the command line:

In my case it's the default PNG, 8-bits, RGBA with 15% compression, but it reliably crashes with JPEG and no matter what settings I use.
I already tried loading the factory defaults first but to no avail.

Confirmed here. Linux Mint 19.1, GTX 1080ti

I remember reporting something very similar some time ago: https://developer.blender.org/T61607

I can confirm it on my side. Linux Mint 19.1 / GTX 1080ti. Very latest build of 2.80.

OK, just tried it and it works. New dependency graph?

In T53341#614867, @Sergey Sharybin (sergey) wrote:

@Steffen Dünner (SteffenD), do you mind testing latest build from builder.blender.org?

Have you tried loading the factory settings before? Might be an old startup.blend or preferences saved from an older version of 2.80.
It's also strange that your splash screen says "Branch: blender2.7" while a proper splash screen should look like this:

Thanks for the quick help. Working perfectly now with 2.79 and 2.80 :)

Can you attach a PNG showing that problem? I have no problems here (2.79 and 2.80 no matter what version). I suspect it's an issue with your display driver (or its settings) or another piece of software that changes the display of images on your laptop.
Do the images @artem ivanov (ixd) posted look OK for you or do they also show banding?

OK, next step. It looks like it's not my user settings but my startup file that contains something that the Multiresolution modifier doesn't like.
If I load factory settings, all is OK. If I load factory settings and then manually load my startup.blend the crash is back...

Here's a debug output with the crash:

Hmm... for me it happens on 3 completely different computers, both with my own compile and the buildbot versions of 2.80.

Oh I see. Thanks!

This task is marked "Closed, Resolved" but the functionality is not yet inside 2.80. So is this still on the agenda?

Sorry, can't confirm your other crash problem

Could be this? https://developer.blender.org/T58183

Sounds a lot like this: https://developer.blender.org/T58183

OK, I think I'm onto something! :)

In T57487#547544, @Roger B (rboxman) wrote:

Perhaps related/duplicate of T57485

Funny. I just compiled the very latest master (17d91bcb611b) and it doesn't crash this easily any more.
But it still crashes reliably in CPU mode with "Accurate Mode" off.
Blender 2.80 same thing.

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

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.

I just gave it another try. Both with 2.79 latest master and 2.80 latest. This time under Windows. No artefacts there as well. So it might be a Mac thing, maybe OpenCL related?!

I guess the problem is not a bug in Cycles but rather a small mistake in your material:

Depending on your hardware and the scene configuration you might need to fiddle a bit with the tile size to find the sweet spot.
In my case it's almost always 32x32 or 64x64 but that can vary. Like with your scene it's 16x16 although I didn't test 8x8.

First question: Are you using "Hybrid" rendering in master?