OpenGL procedurally generated night nebula shader malfunctioning in Minecraft.

[djmrFunnyMan]

This is a continuation from https://community.intel.com/t5/Developing-Games-on-Intel/Driver-level-bugs-causing-issues-in-Minecraft-amp-OpenGL-shaders/td-p/1664368 which will be split into 3 separate reports.

Issue:

Night Nebula function from Complementary Shaders is broken on certain nights.

This issue also isn't present on Nvidia or AMD cards.
The function that drives this effect is located in nightNebula.glsl (in the attached shaderpacks.zip)
(3 showcase images attached)

Reproduction Steps

Preparation:
- Install Iris & Sodium for 1.21.4 : https://github.com/IrisShaders/Iris/blob/multiloader-new/docs/guide.md
- Unpack the shaderpacks.zip inside the (...)\AppData\Roaming\.minecraft folder
- Unpack the Driver Bug Test.zip inside the \AppData\Roaming\.minecraft\saves folder
- Go into options>video settings>shaderpacks and select "complementary unbound 5.4 + euphoria patches 1.5.2"
- Press apply

Reproduction:
- Open the Driver Bug Test world in-game
- Step on the pressure plate that says "Broken Night Sky"
- Step on any of the pressure plates and you should notice graphical issues on the sky

[karen_intel]

@djmrFunnyMan noted!
Adding to debug queue

Karen

[djmrFunnyMan]

I have narrowed down the issue to one line in nightNebula.glsl

return fract(sinM(dot(inCoord, vec2(23.53, 44.0))) * 42350.45);

Changing it to 

return fract(sinM(dot(inCoord, vec2(23.5, 44.0))) * 42350.45);

fixes the issue.

I have no idea why is this the cause. This definitely feels like a bug on your side, because afaik this code meets the spec.

[djmrFunnyMan]

Addendum: The change above does not actually fix the issue. I was mistaken.

I did find another solution which does actually fix the issue.

So for clarity, the following line has issues:

return fract(sinM(dot(inCoord, vec2(23.53, 44.0))) * 42350.45); //unexpected behaviour

Changing it to the following fixes the issue:

uniform float value = 23.53;
return fract(sinM(dot(inCoord, vec2(value, 44.0))) * 42350.45);  //behaves as expected

[Arturo_Intel]

Hello,

I change the code to use uniform and const float with the same value to reproduce this behavior, what I notice is that on latest gen (B390 or series 3) iGPUs, both declarations are behaving the exact same way (abrupt vertical cuts in a procedural noise pattern) which proves that the issue is on how the driver is dealing with this floats. 

I'm still gathering all the evidences possible to push this to the corresponding team. 

A new article will be created to follow this case. I will share the link once is public.

Thanks a lot for your patience,

r2

[djmrFunnyMan]

@Arturo_Intel That's unexpected

On my B580 the two paths differ, with only the left side exhibiting erroneous behaviour.

There may be some difference between iGPU and dGPU drivers.

I suggest you try to run the code on a B580 to compare the difference.

[Arturo_Intel]

Yes, I can confirm on Arc A-Series and B-Series the behavior is as described above: abrupt vertical cuts in a procedural noise pattern.

But in B390 igpu the uniform prefix is behaving as the const/normal float. (in both sides I can see the corruption) 

Indeed we have another level of complexity here.

[Arturo_Intel]

hey @djmrFunnyMan 

I create a homebrew code to reproduce this behavior outside Minecraft based on the path the nightNebula.glsl was following.

here is the repo with the code: https://github.com/Arturo-Intel/06501550

and here is what you will see if you run it

left side is using 23.53

right side is using 23.5

Please review the code and share any input you have.

I will use this to escalate the case to the corresponding team.

--r2

[djmrFunnyMan]

@Arturo_Intel What I managed to figure out is that the issue seems to be related to the number of decimal places of the value actually stored in the float. 
For example 23.53 is actually stored as 23.5300006866455078125 while 23.5 is stored as precisely 23.5. The reason 23.53 has errors is because it has more decimal points than 23.5

The more decimal precision the value actually stored in the float uses up, the more frequent the error is.
For example 23.5 will have less errors than 23.3125 which will have less errors than 23.265625 which will have less errors than 23.53

I still don't know why this is the case but that's the pattern. And to reiterate this issue doesn't manifest on hardware from other gpu vendors.

[djmrFunnyMan]

Just to be clear. The issue isn't that the left side differs from the right side. That is expected.

The issue is the existence of these lines on the left side (highlighted in red)

[djmrFunnyMan]

@Arturo_Intel I provided a lot of information on your github.

https://github.com/Arturo-Intel/06501550/issues/1

https://github.com/Arturo-Intel/06501550/issues/2

Please check out my fork to verify my findings.

Unrelated to the above: I think I should note that a few months ago I created a duplicate report on IGCIT 
To prevent duplicate effort I believe it may need to be closed.

[Arturo_Intel]

Here is the public article on this case:

https://www.intel.com/content/www/us/en/support/articles/000103040.html

--r2

[djmrFunnyMan]

Well I have nothing more to add, other than: good luck!
Hope the issue can be resolved.