Page MenuHome

GPU-rendered tiles look different than CPU-rendered ones
Open, Confirmed, LowPublic


System Information
Operating system: Windows-10-10.0.18362 64 Bits
Graphics card: GeForce GTX 1070 with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.86
CPU: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz

Blender Version
Broken: version: 2.80rc2 (2.80 (sub 74), branch: master, commit date: 2019-07-18 14:52, hash: rB38d4483c6a51)

Short description of error
When rendering a mandelbulb volumetric thing on cycles using CPU and GPU, the two have very different ideas on how the scene should look like, making the individual tiles clearly visible.


(most tiles are GPU-rendered, note the stray red CPU-rendered tile to the left)


Potentially useful information

  • T50193 may be the same bug; I opened a new one because that bug doesn't report differences within a single frame, and is from 2016.
  • Since most of this object is endless math nodes, it may be some sort of floating-point thing that works differently on CPUs and GPUs.
  • I was following this tutorial:
  • I noticed that some operations for which I expected single inputs (namely the sines) had two inputs. In the tutorial, the dude said the second input doesn't do anything, but then, that's from the alpha. Maybe taking a 0.5th sine of a value does something strange?



Event Timeline

How much of your GPU memory is used? I'm asking because I might have a similar issue.
For me, this occurs, when GPU memory is close to full. Then, some geometry seems to be omitted from the GPU, resulting in a tiled look. I'm using Microdisplacement btw.

GPU Memory is at 2.2GB, out of 8GB dedicated, 16GB dedicated+shared

Ok... thanks for the info. It seems unrelated.

I was going to report a similar issue I was having with volumetrics. I use a rx 580 8gb on linux (ubuntu 18.04) with the amdgpu driver (non pro) and blender 2.8 rc2

try changing this setting to distance

LazyDodo (LazyDodo) lowered the priority of this task from Needs Triage by Developer to Needs Information from User.Jul 22 2019, 10:29 PM
LazyDodo (LazyDodo) raised the priority of this task from Needs Information from User to Needs Triage by Developer.Jul 22 2019, 10:37 PM

nope, that did not work either. i'll leave it for someone smarter.

Reproduces here (Win 10/Nvidia 1060). You can reduce the tile size and sampling and still see the issue. I note that the YouTube tutorial's final .blend file does not exhibit the problem when switched to Cycles (but then it has a somewhat different shader setup). It appears to be a very small progressive difference as it moves through each of the stages in the shader. If you remove most of them then the issue is invisible. As you add back in more of the top-level node groups, the problem kind of fades into existence and becomes more pronounced.

I looked for differences in settings, lighting etc. but nothing jumped out. I think it's probably just a very slight difference in the render kernels. It can be *really* hard to get identical floating-point behavior from two different code implementations.

When you use the Math node with a function like Sine that only takes a single value, the second input just stays unused and It will not matter what input it gets.

Sergey Sharybin (sergey) lowered the priority of this task from Needs Triage by Developer to Waiting for Developer to Reproduce.

There is actually a code to ensure Distance sampling is used for all shaders when there are both CPU and GPU are involved, which seems to work the way it is designed to.

I can not reproduce the issue with the mandelbrot file. And it doesn't look like something what could be caused by different shading capabilities on GPU and CPU. But i can not reproduce the issue.

The aeroLux1 issue is that there are two volume domains, which are exactly matching together. It is possible that due to different precision on CPU and GPU one of the intersections is missing when ray exits the domains, causing integration loop to discard volume to avoid overblown pixel due to missive texture.
Just make one of the domains slightly bigger.
Not sure we can do anything about it.

@Brecht Van Lommel (brecht), mind trying to reproduce the first issue?

Hm... now I'm not sure. I'll just post these pictures and let Devs decide if this could be related.
My scene has Volumes in there, but I disabled them to pinpoint the problem. DoF or Volumes don't seem to make a difference for this.

This first image shows the issue. The GPU tiles omit some geometry in front. (See left side of the jaw for example.)

In this second image I just pulled the camera back a little. Since my scene uses Microdisplacement, this reduced the memory consumption just below the critical point and the image looks fine. (I just stopped the render because it takes quite a long time)

I'm rendering with a 1080Ti with 11GB of memory. The second image needed about 9.3GB. Just above that, it starts looking like the first image.

If this is helpful to the issue or I can provide anything else, please let me know.
I can provide the .blend file, but relatively heavy and probably depending on the hardware if the issue shows up or not. Let me know if you believe it's helpful or if I can provide anything else.

Brecht Van Lommel (brecht) lowered the priority of this task from Waiting for Developer to Reproduce to Confirmed, Low.Wed, Sep 25, 5:32 PM

I can reproduce the mandelbrot issue. The other issues reported here seem unrelated, and should be reported separately.

This is a small precision difference between math on the CPU and GPU in one of the shader nodes, which gets worse with every iteration until it has a big visible effect.

We need to figure out which node and operation exactly causes the issue. But we may not be able to fix this, the math function implementations on the GPU may be slightly different and we are not likely to implement our own, because of the performance impact.