Confirmed, Eevee only.

Sorry but i cant understand where the issue comes from.

Where is the z-fighting come from?
There is only one plane, no overlying geometry.

@Rigoletto Eikenberg (rigoletto) this is normally a result of float precision, the object coordinates will be calculated on the fly and the result maybe positive 0.0 or negative 0.0.

@Evan Wilson (EAW) if you mean modify the manual, yes this was updated after porting Checker to GN.

I'd mark it as a known issue (with mitigation shown in manual) or ask someone from the rendering module to take a look.

In T93219#1258117, @Rigoletto Eikenberg (rigoletto) wrote:

Sorry but i cant understand where the issue comes from.

Where is the z-fighting come from?
There is only one plane, no overlying geometry.

Cell Noise is discontinuous at exact integer units. Cycles (and Blender Internal before 2.80) adds an epsilon offset to give better visual results. It appears EEVEE doesn’t have this epsilon offset.

There is code to prevent this in Eevee checker texture.

Eevee

void node_tex_checker(
    vec3 co, vec4 color1, vec4 color2, float scale, out vec4 color, out float fac)
{
  vec3 p = co * scale;

  /* Prevent precision issues on unit coordinates. */
  p = (p + 0.000001) * 0.999999;

  int xi = int(abs(floor(p.x)));
  int yi = int(abs(floor(p.y)));
  int zi = int(abs(floor(p.z)));

  bool check = ((mod(xi, 2) == mod(yi, 2)) == bool(mod(zi, 2)));

  color = check ? color1 : color2;
  fac = check ? 1.0 : 0.0;
}

Cycles

ccl_device float svm_checker(float3 p)
{
  /* avoid precision issues on unit coordinates */
  p.x = (p.x + 0.000001f) * 0.999999f;
  p.y = (p.y + 0.000001f) * 0.999999f;
  p.z = (p.z + 0.000001f) * 0.999999f;

  int xi = abs(float_to_int(floorf(p.x)));
  int yi = abs(float_to_int(floorf(p.y)));
  int zi = abs(float_to_int(floorf(p.z)));

  return ((xi % 2 == yi % 2) == (zi % 2)) ? 1.0f : 0.0f;
}

Below is a possible fix for the checker texture by detecting negative coordinate values below 1e-05.

/* Prevent precision issues on signed zeros. */
  p.x = (abs(p.x) <= 1e-05) ? 0.0 : p.x;
  p.y = (abs(p.y) <= 1e-05) ? 0.0 : p.y;
  p.z = (abs(p.z) <= 1e-05) ? 0.0 : p.z;

This doesn't explain why the object coordinates seem to be less stable in Eevee and work in Cycles without this fix.

void node_tex_checker(
    vec3 co, vec4 color1, vec4 color2, float scale, out vec4 color, out float fac)
{
  vec3 p = co;

  /* Prevent precision issues on signed zeros. */
  p.x = (abs(p.x) <= 1e-05) ? 0.0 : p.x;
  p.y = (abs(p.y) <= 1e-05) ? 0.0 : p.y;
  p.z = (abs(p.z) <= 1e-05) ? 0.0 : p.z;

  p *= scale;

  /* Prevent precision issues on unit coordinates. */
  p = (p + 0.000001) * 0.999999;

  int xi = int(abs(floor(p.x)));
  int yi = int(abs(floor(p.y)));
  int zi = int(abs(floor(p.z)));

  bool check = ((mod(xi, 2) == mod(yi, 2)) == bool(mod(zi, 2)));

  color = check ? color1 : color2;
  fac = check ? 1.0 : 0.0;
}

@Charlie Jolly (charlie) thanks for making the explain. I have a clue know where such things come from.
I didnt thought eevee / cycles uses have their own code for the textures or different precision (float vs floatf), so eevee is faster by less precision.

GLSL shaders may be compiled with less precision or aggressive optimization. It would not surprise me if for example a compiler rearranges that into a fused-multiply-add with less precision.

The current epsilon is 1e-06. Instead of adding new logic with 1e-05, we may as well use that higher epsilon in the existing code?

diff --git a/source/blender/gpu/shaders/material/gpu_shader_material_tex_checker.glsl b/source/blender/gpu/shaders/material/gpu_shader_material_tex_checker.glsl
index f534f3b..c404596 100644
--- a/source/blender/gpu/shaders/material/gpu_shader_material_tex_checker.glsl
+++ b/source/blender/gpu/shaders/material/gpu_shader_material_tex_checker.glsl
@@ -4,7 +4,7 @@ void node_tex_checker(
   vec3 p = co * scale;
 
   /* Prevent precision issues on unit coordinates. */
-  p = (p + 0.000001) * 0.999999;
+  p = (p + 0.00001) * 0.99999;
 
   int xi = int(abs(floor(p.x)));
   int yi = int(abs(floor(p.y)));

The reason for this is also because you get the same precision issue at 0.0, 1.0, 2.0, ... . So it should not be specific to values near 0.0.

I spent a little time investigating this. Not an obvious solution at present.

Higher epsilon causes shifting issues when scale is very small.
Eevee left, Cycles right

The can be fixed by changing the epsilon using the sign of the coordinates.

/* Prevent center shift on small values. */
vec3 s;
float d = 0.00001;
s.x = p.x < 0.0 ? -d : d;
s.y = p.y < 0.0 ? -d : d;
s.z = p.z < 0.0 ? -d : d;
p *= scale;

/* Prevent precision issues on unit coordinates. */
p = ((p + s) * 0.99999);

Fixed centered checker. This would break existing behaviour.
Eevee left, Cycles right

Even with low epsilon values, at values near the epsilon there are precision issues
Eevee left, Cycles right

Precision with low epsilon is fixed with the signed zero precision check.

/* Prevent precision issues on signed zeros. */
p.x = (abs(p.x) <= 1e-05) ? 0.0 : p.x;
p.y = (abs(p.y) <= 1e-05) ? 0.0 : p.y;
p.z = (abs(p.z) <= 1e-05) ? 0.0 : p.z;

With both zero check and center fix at scale 0.000001.
Eevee left, Cycles right

Even with the fixes, there is still an issue with cube at scale 1.0

Could it be the problem comes from the "mod" function? There may be differences mod vs %.

I think shifting when the scale is very small is acceptable.

I don't see a reason to think the problem comes from mod.

Overall the result is slightly better increasing the epsilon but still has issues.

I'll try a few other ideas before creating a patch.

This is the shifting when scale is 0.001.

Issues at scale 42.3.

Issues at scale 1.

I've added a patch for a possible solution by adding option to lock axis on checker texture. I wasn't satisfied with changing the epsilon as a solution.

D13582: Nodes: Add axis lock to Checker texture node

Hello @Charlie Jolly (charlie),
I really don't like flickering so I tried a different approach for a checker texture in P2665.
For me that was stable on different orders of magnitude but as every GPU has a different
take on math maybe that is worse on different hardware.

@Michael (michael64) I'll take a look and report back.

Seems like it works in a similar way to increasing the epsilon.

Scale: 0.001 - shifting from center

Scale: 8.000 - different pattern to cycles

I haven't found a nice way of solving this issue other than providing option for 2D texture in D13582.

Change status to known issue and add the link to the workarounds in the manual here:

https://docs.blender.org/manual/en/latest/render/shader_nodes/textures/white_noise.html#notes