Incorrect conversion result of Vulkan float/uint conversion on Intel UHD 730

[KlotenSchweiz]

Converting a float to uint and then back to float on Vulkan gives inconsistent result on Intel UHD 730. Consider the following code snippet in the fragment shader:

const uint UINT_MAX = 4294967295u;
uint u = UINT_MAX - 127u;
float f = float(u);
uint u2 = uint(f);

Ideally, the final value of u2 should be `UINT_MAX - 127u`. However, when executing the code on Intel UHD 730, the value of u2 is unexpectedly 0, which is far from the expected value. The conversion from uint to float and back to uint should not greatly change the value of the original uint.

Interestingly, when slightly tweaking the initial value of variable `u` to be `UINT_MAX - 128u`, the final value of `u2` becomes correct.

This issue does not occur on AMD GPU, where the final value of `u2` is always the expected value in both cases.

Steps to reproduce:

I made a minimal fragment shader that simply outputs the value of u2 as the fragment color. I also provide a Vulkan application that loads the fragment shader. The full package can be downloaded here. It also contains a detailed README file to show the execution environment and reproduction steps. It should take less than a minute to reproduce the issue.

[DeancR_Intel]

Hi KlotenSchweiz,

Apologies for the delay in my response. This is just to ask if you're one of the developers of that game or application.

Let us know if you have any other questions.

Best regards,

Dean R.

Intel Customer Support Technician

[KlotenSchweiz]

Thanks for your reply. I am a developer who likes to use shaders to render fancy effects. I got distorted rendering results when I am trying to write a shader program to get a procedural texture. After some manual investigation, I got the minimized program above that can still produce the issue.

[DeancR_Intel]

Hi KlotenSchweiz,

Thank you for posting in the community!

This is well noted and to ensure you receive the most specialized assistance, we have a dedicated forum that addresses these specific concerns. Therefore, I will be moving this discussion to our developer forum. This will allow our knowledgeable community and experts to provide you with timely and accurate solutions.

Best regards,

Dean R.

Intel Customer Support Technician

[karen_intel]

Hello hello @KlotenSchweiz Welcome to our Intel Game Developer Support Forum

Ty for sharing your project package. I have successfully downloaded it

I'll find out about tweaking the initial value of variable `u` to be `UINT_MAX - 128u`, considering that the final value of `u2` becomes correct. I have to create an internal report for that and check with the driver dev team why is it behaving like this.

Please share your SSU to have full product specs

Also, could you please include what's the impact of this behavior? IE: are you working in a game, app?

I need those details for my report, please share as soon as you can so I can include them

Thanks a lot, talk to you soon

Karen

[KlotenSchweiz]

@karen_intel Thanks for your prompt response! I am attaching the information from SSU on my PC for your reference.

I am developing a game with rich textures on objects. I came across this bug when I am producing a procedural texture with graphics shader programs for my game. I expect that the texture to have smooth transition colors, but I spotted drastic color changes near the edge of my texture, i.e., when the input integer is close to UINT_MAX. It makes the texture to have an unnatural color.

[karen_intel]

@KlotenSchweiz understood. Thanks a lot

I'll get back soon with my findings as I have a couple cases on queue

Talk to you soon

Karen

[KlotenSchweiz]

@karen_intel That's great!

[KlotenSchweiz]

Sorry for interrupting. I encountered another incorrect rendering results on a fragment shader program. The issue only appears on Intel but does not appear on NVIDIA or AMD.

This shader program contains a series of ternary expressions and somehow confuses the Intel shader compiler. I manually reduces this program and the following one is the minimal one that can still reproduce the issue:

#version 310 es

precision highp float;
precision highp int;

const uint UINT_MAX = 4294967295u;

layout(location = 0) out vec4 color;

layout(binding = 0) uniform Uniform {
    int input1; // input1 = 1
    int input2; // input2 = 1
};

void main() {
  int a = 0;
  int b = 0;
  int c = input1 <= 2 ? input1 : 1; // c = 1
  a = uint(input1) != UINT_MAX ? input1 : input1 + c; // a = 1
  if (uint(input2) > 1u ? a < 2 : uint(input1) == UINT_MAX) // false
    b = 1;
  color = vec4(vec3(b), 1.0); // color = vec4(0.0, 0.0, 0.0, 1.0)
}

The two inputs input1 and input2 are both initialized to 1.. The main function performs the following:

• Initializes two integers a and b to 0.
• Calculates c based on input1: if input1 is less than or equal to 2, c is set to input1; otherwise, it's set to 1. Since input1 is 1, c becomes 1.
• Updates a: if input1 is not equal to UINT_MAX, a is set to input1; otherwise, it would be input1 + c. Here, input1 is 1, so a becomes 1.
• Evaluates a condition: if input2 (1) is greater than 1, it checks if a (1) is less than 2; otherwise, it checks if input1 is equal to UINT_MAX. Since input2 is not greater than 1, it evaluates uint(input1) == UINT_MAX, which is false (1 is not equal to UINT_MAX).
• Since the condition is false, b remains 0
• Set the final color to vec4(vec3(b), 1.0), which is vec4(0, 0, 0, 1) meaning black.

I also prepare a package that can reproduce this issue in a push-button manner. You can download it here and follow the instructions in README.md.

I would appreciate it if you could have a look at this issue as well. It would greatly help me avoid the troubles in my shader design.