Visual difference between GPU and CPU rendering path

[marshats]

Pop!_OS 24.04 LTS
Vulkan Instance Version: 1.3.280

$ VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nvidia_icd.json vulkaninfo | grep “GPU id : 0”
GPU id : 0 (NVIDIA GeForce RTX 3050):

vs

$ VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/lvp_icd.json vulkaninfo | grep “GPU id : 0”
GPU id : 0 (llvmpipe (LLVM 19.1.1, 256 bits)):

I compile the examples from GitHub - pocdn/Vookoo: A set of utilities for taking the pain out of Vulkan in header only modern C++ with no issues. The example 08-cybertruck gives different visual results depending on which driver is used. There is no change in the executable itself but changing VK_ICD_FILENAMES
from /usr/share/vulkan/icd.d/nvidia_icd.json
to /usr/share/vulkan/icd.d/lvp_icd.json
demonstrates the visual difference between GPU vs CPU driver.

Notice the screenshot on the left-side, using Nvidia GPU, has significant discontinuities in the floor (highlighted with added red marker lines) but the right-side image, using CPU (llvmpipe), shows no such discontinuities. Is this a commonly known driver issue or likely some Vulkan initialization issue? Any suggestions where in the vookoo code to focus on debugging this problem?

Note this example comes from a fork of original Vookoo. The fork contains additional examples such as this 08-cybertruck being discussed here.

Also the exact command line commands to create the screenshot are:
VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nvidia_icd.json ./08-cybertruck
vs
VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/lvp_icd.json ./08-cybertruck

[Sascha_Willems]

This is mostly likely an application and issue and can be caused by not properly implementing Vulkan and/or not taking implementation limits and features into account.

[marshats]

Thanks for pointing to the problem being in not taking into account limits and features of Vulkan. By changing fragment shader i.e. float->float64_t, vec2->dvec2, vec3->dvec3, vec4->dvec4 and adding missing sin, cos, exp, atan functions of the same float64_t, etc, at the expense of drastic loss in FPS, the discontinuities did go away as seen in screenshot. Note also had to include

#extension GL_EXT_shader_explicit_arithmetic_types_float64 : enable

After reading some more about differences in webGL, openGL, and Vulkan shaders, Vulkan shader usage is more explicit when it comes to bit precision/length whereas the others seem to make less conservative assumptions by default.
So looks like the problem lies in the shader itself and not directly with the Vulkan cpp initialiation code. Does that seem true or are there some possible VkPhysicalDeviceFeatures or something similar that could be changed instead of the floating types used in the shader itself?

Note, I created a test openGL 4.6 code that read the original fragment shader unchanged and it resulted in a visually clean image without having to explicitly use double types.