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?

Hi there,

This is not a bug.

After finishing the job that caused me to post this "bug report", I somehow lost sight of this ticket. But on second thought it might actually be worth to re-open it again for the exact reason that ronan mentioned.
Render size and simulation size should both be available but the render size should never affect the simulation. Quite the same as changing the instanced object or group doesn't affect the simulation. You should still be allowed to change render settings after caching a simulation.

I don't know it this helps but if I open an image editor and manually set the color space of both the normal and the roughness maps to "Linear" instead of "sRGB" the packed version also renders fine.
Seems to ignore the non-color data setting of the image texture nodes.

Well, here is what Houdini 16.5 says to the attached .abc file.

Gave it 10 more tries, no crash. It also works reliably with the brand new "Transparent Glass" feature. :)

Last night it crashed for me (Linux Mint 18.3, 12GB RAM, GTX780 3GB), but now with the very current master it works:

OK, I tried to reproduce my problem today with the very latest own build and couldn't reproduce it. I can now slowly but successfully render the benchmark scene on my +10 years old system with only 12GB of RAM and a GTX780 3GB (on Linux Mint that is).
I don't know what fixed it, but at least this is now working properly. Great work! :D

In my case it's not so easy I guess. I just gave it another try on my 10+ years old dual Xeon system with Linux Mint 18.3 and the very latest master of Blender (own compile).
It's just the Gooseberry benchmark scene switched to use GPU only. I also made sure to only use the GPU (GTX780 3GB) not the CPU or both.
The result is that it starts rendering although the scene would use more than twice the amount of GPU RAM. This is great.
The problem is that the final result is very very dark. I interrupted the rendering but here's a screenshot:

In rBc621832d3d358cd7648d60c16e1685050c4f6778#163939, @derek barker (lordodin) wrote:

I cant manage to get the Gooseberry benchmark to render.

I'm not at home at the moment so I can't help with testing stuff, but the TdrDelay issue affects almost any application using CUDA. Allegorithmic Substance Designer and Painter now even display warnings if they find default values in the registry and strongly advise you to change the settings accordingly.
Here's a helpful article on that https://support.allegorithmic.com/documentation/display/SPDOC/GPU+drivers+crash+with+long+computations

Hi Christoph,

Thanks, I actually had render crashes in this project, but it was too weird to reproduce easily. Also I am currently too swamped with work. Hopefully you can kill all these bugs ;)

@Brecht Van Lommel (brecht) You are a wizard! Thanks a lot!

Awesome!

I used the new CPU + GPU option in this case.

Confirmed here. Win10 x64, GTX1080Ti

This is perfectly normal and expected.

Tiny comment:

Have you tried the latest Buildbot builds?
I had a similar bug that was fixed some time ago: https://developer.blender.org/T52479

OIC, thanks for your fast response.

Confirmed on my side.

Obviously a duplicate of https://developer.blender.org/T52687

Thanks for confirming this. Yes, it "works" when scaling first, but in my case all the filters were set to a specific look and I was about to start the playout for the final delivery of several shots in 4k when all of a sudden I noticed this bug.
In the end I started resizing all of the render pictures with Fusion.