This seems to be the most used solution I can find:

In T68920#795532, @Brecht Van Lommel (brecht) wrote:

@Laurent Noel (c2ba), I think someone should try an automatic solution before we add manual settings.
The issue happens when a reflection ray goes into the mesh, and then wrong shadow comes from when it exits. So if we ignore that exit, it may solve the most common type of problem. It's even possible to experiment with this using just a shader setup with a transparent BSDF on the backside, to see how well it works. Either way, any solution will need changes to the BSDF evaluation first.

same problem with volumes too? identical model left and right

Really？But I can reproduce it here every single time!

Test scene still does not work properly with 2.81 build 14 Oct 2019

May be related to T66529

Add trunc and snap

In T70772#795100, @Jacques Lucke (JacquesLucke) wrote:

Did this work in earlier versions of Blender?

@Laurent Noel (c2ba), I think someone should try an automatic solution before we add manual settings.

I can replicate, but I'm not sure if the problem is in the file or in Cycles.

Smaller worked. This was an obvious pointer overflow within Cuda. The texture size crossed the limit of positive values for a 31-bit float (bits 0-30 being the value; bit 31 being the sign bit). With bit 31 set, pointers were being treated as negative numbers. Why are they using 32-bit ANYTHING with today's cards? Oh well. Now it's known that limit exists. This is why I hate high level languages.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

Did this work in earlier versions of Blender?

I can confirm the issue.

I've just spoken to Jules Urbach from Octane, he's going to ask Lino from his Dev team to help you out.

In T68920#794109, @Brecht Van Lommel (brecht) wrote:

I'd prefer us to first try a better solution, like ignoring backfaces, which may not be all that complicated.
Also as described in T37814#773025, this needs changes in BSDF evaluation too.

I'd prefer us to first try a better solution, like ignoring backfaces, which may not be all that complicated.

I get the same result. Here's a less noisy version.

I managed to run a few tests and it works!

confirmed. This is a major issue!

I want to add that this is not just an error that appears in very few situations. It appears (for my understanding) for nearly every realistic sized light (lights <1m).
I have a big project where I can render no single frame without this error. ~90% of the light comes from area lights (10x10cm floor lights).
It looks like the contrast or brightness setting is different when rendering with CPU or GPU. GPU frames are always a lot brighter than CPU frames. I currently don't know which device produces the correct output. It's annoying and very time consuming that you cannot use both devices at the same time anymore to speed up rendering.

Another possible workaround is the operator "make instances real". Execute, then deactivate the particle system. At least for rendering still images it worked for me, before I sent the file to our renderfarm.

Move inversesqrtf to function

For anyone requiring a work-around for this bug, I have been able to successfully render from the terminal by rendering one eye at a time, and manually combining both left and right eyes into one image, after the render is complete.

Maths Node: Additional functions

I am able to replicate this bug without rendering from command line. Scene is complex, and is being rendered out in spherical (equirectangular) stereoscopic format. Cycles, affects both GPU and CPU render.

In T49234#791232, @Kévin Dietrich (kevindietrich) wrote:

You have to apply the patch and compile Blender to test the feature, it is not in the daily builds. Also your file does not have velocity information (the array size is 0). So without the patch and without custom velocities, Cycles is just using an interpolation between the previous, current, and next frames.

Pablo suggested poking. So i'm poking :) Increasing motion blur steps doesn't help.

You have to apply the patch and compile Blender to test the feature, it is not in the daily builds. Also your file does not have velocity information (the array size is 0). So without the patch and without custom velocities, Cycles is just using an interpolation between the previous, current, and next frames.

I have some blurriness, but it doesn't seem to look right. (see Images)
This is a particle system that I exported and then reimported to reverse the movement. And the plane is a dupliobject on the vertices of the ABC.
I would not expect to see a clear outline of the plane in the image with motion blur. Also, the position of the blur is set to Center. But this seems more like Start. And the shutter duration also has no effect.

For those who haven't noticed, I updated and fixed the patch D2388, please try it if you can!

Can confirm, checking... seems code in BlenderSync::sync_world still relies on a blender world (mixes the background color with the viewport color), will have a look.
[eeve seems to pick the theme color as a fallback if no world is present? maybe cycles should do this as well -- or just black...]

In T66855#788826, @Dalai Felinto (dfelinto) wrote:

Talked to @Brecht Van Lommel (brecht) and this is indeed a bug, however volume + render passes has always been weak, thus this is not a high priority:
"It's more of a design issue really, no way to cleanly separate volumes and render passes. So we have to make some choices or add settings to control it."

Talked to @Brecht Van Lommel (brecht) and this is indeed a bug, however volume + render passes has always been weak, thus this is not a high priority:
"It's more of a design issue really, no way to cleanly separate volumes and render passes. So we have to make some choices or add settings to control it."

I can confirm.
You can easily observe by selecting one of the invisible objects and enabling the Ray Visibility Camera option.

It's 2 GB actually, but anyway - thanks for claering things up, will jsut render at CPU if GPU crushes.

I can do full rendering again. I do not know why but if I render with a Tile Size equal to the final resolution all works normally.
The problem is that I can not enjoy my PCs with multiple GPUs.

OK thanks, that looks like it’s confirming that you are just hitting the limits of your GPU here, GT 740 is a pretty low-level entry one from 2014, with only 1GB of memory… It won’t make miracles. You can follow the link given at the end of those messages (https://docs.blender.org/manual/en/latest/render/cycles/gpu_rendering.html), but this probably won't help much in that case.

This is a compiler bug in the ROCm drivers, which we don't support yet for Cycles. Many changes to the Cycles kernel were made since 2.79b.

There's people in the world who never really used CMD, and i'm one of them. This commands tells NOTHING on how and in which order they should go;
However, after reading about CMD itself and one more half an hour later i figured all out, here's the .txt file with all that console recorded:

strange, the download link worked in the report preview. I have tried again.

To address this issue, what do you think about adding a "shadow bias" parameter to control an offset from the surface along the geometric normal ? I know its not a perfect solution but at least it would allow users to avoid a lot of rendering artifacts that are due to shadow termination.

Don’t want to be rude, but seriously… http://letmegooglethat.com/?q=blender+command+line will give you all you need to know in the two or three first answers…

1. Yep, using latest driver version; GeForce Game Ready Driver, version 436.48, release date (Month/Date/Year) 10.1.2019

I will try to dig deeper and produce simplistic deterministic case. I had problems with Motion blur on other PC also, where it just straight crashed when GPU tried to render the frame (https://developer.blender.org/T69908), same version of 2.81.

I am afraid I cannot reproduce this...

Most likely a limitation of GPU computing indeed, we'd need to know your driver version though, and please ensure that it is the latest available from official nvidia website.

Ok, that's fine then.

It's the terms nvidia users to distinguish between high level virtual architecture (ptx) and actual code(sm)

I don't understand why "sm" means "cubin" and "compute" means "ptx", is that a standard thing?

The main helpful thing for me is that this is an option I can always have enabled, whereas WITH_CYCLES_CUDA_BINARIES I quite often enable/disable to save on compile time.

Do you have more reasoning on why ? and why this would benefit windows devs more than other devs?

@Lukas Stockner (lukasstockner97) good catch, thanks!

• Merge branch 'cuda_ptx' of github.com:skwerner/blender into cuda_ptx
• Fixed a typo.

Seems reasonable to me, just one comment.

@Mai Lavelle (maiself), I'm not sure if this involves adaptive render subdvision, but can you take a look?

I have made all the fixes related to getting single device_network/server working for basic tile rendering for 2.8. Multiple network device still needs testing and iterating. Also progressive rendering does not work with network device rendering. I maybe able to spend sometime to get that to work. At which time I will post a patch.

The baking "crash" is really just the regression tests misreporting what happened, not critical for 2.81 then.

@Philipp Oeser (lichtwerk) just a little improvement, if the file is updated, the scratches of the metal should not move like reflections :)

According to me behavor in CYCLES is OK.
EEVEE seems to drop the frame offset of image texture nodes. Only when multiple nodes point to the same image file sequence.

Hi Max,

Hi Andy,

I think normally adaptive subdivision should be able to handle this kind of case without creating degenerate geometry, but it needs closer investigation to see what is happening here specifically.

Volume interaction with render passes is quite weak still, this is something to revise.

@Julian Siversen (sivert3) I understand your reply but the new voronoi code is very different and this patch is no longer applicable. I might take a look at adding it to the 3D type but I’m also stuck without a Cycles equivalent of the OSL ‘calculatenormal(P)’ function.

Not so fast. Distance along surface normal to edge as implemented here is a different operation than distance to edge in D5743 and cannot be replicated by the features added in that patch. The reason to do distance along surface normal is that you get consistent derivatives along the surface, the original devtalk past linked at the top shows an illustration of how distance along surface normal (left) approximately compares to distance to nearest edge (right).

Some features from this patch would still be nice but would need to be reworked since Voronoi changes in D5743.