Eevee: math wrap and floor, AMD Driver precision issues #88151

New Issue

Eyad Ahmed · 2021-05-09T19:43:49+02:00

Eyad Ahmed commented

2021-05-09 19:43:49 +02:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: Radeon RX 5500 XT ATI Technologies Inc. 4.5.14831 Core Profile Context 21.5.1 27.20.21003.1028

Blender Version
Broken: version: 2.92.0, branch: master, commit date: 2021-02-24 16:25, hash: 02948a2cab
Blender 2.83 LTS has same problem

Short description of error
Math and Vector Wrap give different results for Eevee and Cycles, also doesn't swap min max, when max is less than min

More info
This is important for an upcoming Shader Nodes patch that relies on wrap operation
also for shader setups that rely on this

other people tested this, the problem seems to appear only on AMD Windows

Exact steps for others to reproduce the error

When Using -3 as Min for wrap, and 3 as max, some values give different results in Eevee than in Cycles
Floor operation is probably the cause of this
this node setup

Cycles

Eevee

eevee_math_wrap_different_from_cycles.blend

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: Radeon RX 5500 XT ATI Technologies Inc. 4.5.14831 Core Profile Context 21.5.1 27.20.21003.1028 **Blender Version** Broken: version: 2.92.0, branch: master, commit date: 2021-02-24 16:25, hash: `02948a2cab` Blender 2.83 LTS has same problem **Short description of error** Math and Vector Wrap give different results for Eevee and Cycles, also doesn't swap min max, when max is less than min **More info** This is important for an upcoming Shader Nodes patch that relies on wrap operation also for shader setups that rely on this other people tested this, the problem seems to appear only on AMD Windows **Exact steps for others to reproduce the error** When Using -3 as Min for wrap, and 3 as max, some values give different results in Eevee than in Cycles Floor operation is probably the cause of this this node setup ![image.png](https://archive.blender.org/developer/F10069114/image.png) Cycles ![cycles.jpg](https://archive.blender.org/developer/F10069116/cycles.jpg) Eevee ![eevee.jpg](https://archive.blender.org/developer/F10069118/eevee.jpg) [eevee_math_wrap_different_from_cycles.blend](https://archive.blender.org/developer/F10069123/eevee_math_wrap_different_from_cycles.blend)

Eyad Ahmed commented

2021-05-09 19:43:49 +02:00

Added subscriber: @IyadAhmed

Eyad Ahmed changed title from ~~Math Node Wrap: Different results for Eevee and Cycles, also doesn't swap min max, when max is less than min~~ to Wrap math operation: Different results for Eevee and Cycles

2021-05-09 20:15:16 +02:00

Eyad Ahmed commented

2021-05-09 20:33:15 +02:00

it seems to be only on AMD/Windows configuration

Eyad Ahmed changed title from ~~Wrap math operation: Different results for Eevee and Cycles~~ to Eevee: wrong results for wrap math operation with AMD Windows

2021-05-10 00:22:59 +02:00

Eyad Ahmed changed title from ~~Eevee: wrong results for wrap math operation with AMD Windows~~ to Eevee: wrong results for wrap and floor math with AMD Windows

2021-05-10 00:23:13 +02:00

Eyad Ahmed changed title from ~~Eevee: wrong results for wrap and floor math with AMD Windows~~ to Eevee: wrong results for wrap and floor math with AMD GPU Windows

2021-05-10 00:58:15 +02:00

Eyad Ahmed commented

2021-05-10 01:06:57 +02:00

Multiple people with non-AMD/non-Windows tested and the issue was not happening for them

Eyad Ahmed changed title from ~~Eevee: wrong results for wrap and floor math with AMD GPU Windows~~ to Eevee: math wrap and floor, AMD Driver precision issues

2021-05-10 03:07:41 +02:00

Jeroen Bakker commented

2021-05-10 07:43:33 +02:00

Added subscriber: @Jeroen-Bakker

Omar Emara commented

2021-05-10 12:40:13 +02:00

Added subscriber: @OmarEmaraDev

Omar Emara commented

2021-05-10 12:40:13 +02:00

I can replicate the issue on Mesa R600g. Software rasterization is identical to Cycles. I can take a look later today.

Eyad Ahmed commented

2021-05-10 17:37:44 +02:00

Great

In #88151#1158562, @OmarEmaraDev wrote:
I can replicate the issue on Mesa R600g. Software rasterization is identical to Cycles. I can take a look later today.

Great > In #88151#1158562, @OmarEmaraDev wrote: > I can replicate the issue on Mesa R600g. Software rasterization is identical to Cycles. I can take a look later today.

Omar Emara commented

2021-05-10 22:37:27 +02:00

Added subscriber: @CharlieJolly

Omar Emara commented

2021-05-10 22:37:27 +02:00

@CharlieJolly The max and min inputs of the wrap function seems to be inverted, at least relative to the Godot code, is that intended? Also can you take a look at this?

@IyadAhmed Seems to be a precision issue indeed. floor((value - minValue) / (maxValue - minValue)) may be zero when it should ideally be 1 for off-one-division results. Not sure what should be done here. Lets wait for Charlie's opinion on this.

@CharlieJolly The max and min inputs of the wrap function seems to be inverted, at least relative to the Godot code, is that intended? Also can you take a look at this? @IyadAhmed Seems to be a precision issue indeed. `floor((value - minValue) / (maxValue - minValue))` may be zero when it should ideally be 1 for off-one-division results. Not sure what should be done here. Lets wait for Charlie's opinion on this.

Eyad Ahmed commented

2021-05-10 23:24:02 +02:00

In #88151#1158936, @OmarEmaraDev wrote:
@CharlieJolly The max and min inputs of the wrap function seems to be inverted, at least relative to the Godot code, is that intended? Also can you take a look at this?

@IyadAhmed Seems to be a precision issue indeed. floor((value - minValue) / (maxValue - minValue)) may be zero when it should ideally be 1 for off-one-division results. Not sure what should be done here. Lets wait for Charlie's opinion on this.

Great, many thanks for working on the issue
Also for swapped values, max and min should be swapped when max is less than min I think

> In #88151#1158936, @OmarEmaraDev wrote: > @CharlieJolly The max and min inputs of the wrap function seems to be inverted, at least relative to the Godot code, is that intended? Also can you take a look at this? > > @IyadAhmed Seems to be a precision issue indeed. `floor((value - minValue) / (maxValue - minValue))` may be zero when it should ideally be 1 for off-one-division results. Not sure what should be done here. Lets wait for Charlie's opinion on this. Great, many thanks for working on the issue Also for swapped values, max and min should be swapped when max is less than min I think

Charlie Jolly commented

2021-05-11 12:52:09 +02:00

Works fine here on Windows/Intel.

In #88151#1158936, @OmarEmaraDev wrote:
@CharlieJolly The max and min inputs of the wrap function seems to be inverted, at least relative to the Godot code, is that intended? Also can you take a look at this?

The inputs are swapped around probably to match the UI parameter order which uses a, b and c.

@IyadAhmed Seems to be a precision issue indeed. floor((value - minValue) / (maxValue - minValue)) may be zero when it should ideally be 1 for off-one-division results. Not sure what should be done here. Lets wait for Charlie's opinion on this.

Probably is a precision issue. Division by zero should be avoided as range is checked before the divide operation.

Min, max values could be swapped but this is a change in behaviour.

I can't test AMD here unfortunately.

Works fine here on Windows/Intel. > In #88151#1158936, @OmarEmaraDev wrote: > @CharlieJolly The max and min inputs of the wrap function seems to be inverted, at least relative to the Godot code, is that intended? Also can you take a look at this? The inputs are swapped around probably to match the UI parameter order which uses a, b and c. > @IyadAhmed Seems to be a precision issue indeed. `floor((value - minValue) / (maxValue - minValue))` may be zero when it should ideally be 1 for off-one-division results. Not sure what should be done here. Lets wait for Charlie's opinion on this. Probably is a precision issue. Division by zero should be avoided as `range` is checked before the divide operation. Min, max values could be swapped but this is a change in behaviour. I can't test AMD here unfortunately.

Eyad Ahmed commented

2021-05-11 20:26:49 +02:00

another observation, adding a small value before wrap produces wrong results both on Cycles and Eevee, possibly on non-AMD as well

another observation, adding a small value before wrap produces wrong results both on Cycles and Eevee, possibly on non-AMD as well ![image.png](https://archive.blender.org/developer/F10080537/image.png)

Charlie Jolly commented

2021-05-11 21:43:11 +02:00

The code is consistent. I think the sockets maybe labelled incorrectly. Not sure why this happened, could be oversight in original patch. The bug then maybe caused by the issue that max is less than min.

OSL: calls wrap(Value1, Value2, Value3);

float wrap(float value, float max, float min)
{
  float range = max - min;
  return (range != 0.0) ? value - (range * floor((value - min) / range)) : min;
}

Cycles SVM: calls wrapf(a, b, c)

ccl_device_inline float wrapf(float value, float max, float min)
{
  float range = max - min;
  return (range != 0.0f) ? value - (range * floorf((value - min) / range)) : min;
}

Eevee: calls wrap(a, b, c)

float wrap(float a, float b, float c)
{
  float range = b - c;
  return (range != 0.0) ? a - (range * floor((a - c) / range)) : c;
}

Geo Nodes: calls math_function(a, b, c)

MINLINE float wrapf(float value, float max, float min)
{
  float range = max - min;
  return (range != 0.0f) ? value - (range * floorf((value - min) / range)) : min;
}

@IyadAhmed Can you check again but swapping min and max. Can you also check with OSL too?

The code is consistent. I think the sockets maybe labelled incorrectly. Not sure why this happened, could be oversight in original patch. The bug then maybe caused by the issue that max is less than min. ``` OSL: calls wrap(Value1, Value2, Value3); float wrap(float value, float max, float min) { float range = max - min; return (range != 0.0) ? value - (range * floor((value - min) / range)) : min; } ``` ``` Cycles SVM: calls wrapf(a, b, c) ccl_device_inline float wrapf(float value, float max, float min) { float range = max - min; return (range != 0.0f) ? value - (range * floorf((value - min) / range)) : min; } ``` ``` Eevee: calls wrap(a, b, c) float wrap(float a, float b, float c) { float range = b - c; return (range != 0.0) ? a - (range * floor((a - c) / range)) : c; } ``` ``` Geo Nodes: calls math_function(a, b, c) MINLINE float wrapf(float value, float max, float min) { float range = max - min; return (range != 0.0f) ? value - (range * floorf((value - min) / range)) : min; } ``` @IyadAhmed Can you check again but swapping min and max. Can you also check with OSL too?

Eyad Ahmed commented

2021-05-11 22:09:31 +02:00

Sure swapping is same problem, this is a different problem than with AMD driver, it happens on all
to make it clear adding a small value to input, makes it always act as if max is less than min, even if you write values swapped

OSL

here's "correct" result for comparison

Sure swapping is same problem, this is a different problem than with AMD driver, it happens on all to make it clear adding a small value to input, makes it always act as if max is less than min, even if you write values swapped ![image.png](https://archive.blender.org/developer/F10081590/image.png) OSL ![image.png](https://archive.blender.org/developer/F10081593/image.png) here's "correct" result for comparison ![image.png](https://archive.blender.org/developer/F10081595/image.png)

Charlie Jolly commented

2021-05-11 23:22:34 +02:00

Here is a file with a nodegroup implementing the wrap function that may help troubleshoot the issue. The labels are an easy fix but perhaps leave that until this bug is fixed.

eevee_math_wrap_different_from_cycles_v2.blend

I don't think I can help anymore without an AMD card to test.

Here is a file with a nodegroup implementing the wrap function that may help troubleshoot the issue. The labels are an easy fix but perhaps leave that until this bug is fixed. [eevee_math_wrap_different_from_cycles_v2.blend](https://archive.blender.org/developer/F10082591/eevee_math_wrap_different_from_cycles_v2.blend) I don't think I can help anymore without an AMD card to test.

Eyad Ahmed commented

2021-05-12 00:17:04 +02:00

Cycles (OSL same results as non-OSL)

Eevee
Produces different results

Cycles (OSL same results as non-OSL) ![image.png](https://archive.blender.org/developer/F10083320/image.png) Eevee Produces different results ![image.png](https://archive.blender.org/developer/F10083322/image.png)

Omar Emara commented

2022-02-10 14:33:25 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Eevee: math wrap and floor, AMD Driver precision issues #88151