Vulkan issues on ANGLE-based forks

[Eblo]

Note: As of posting this issue, this main fork for mkxp-z only uses ANGLE on MacOS, and it does not use Vulkan. This issue manifests in my fork which uses ANGLE for all platforms. This bug is being filed here nonetheless in case someone sees it and has insight.

From my testing, this seems to only manifest when using the Vulkan backend on Windows. This does not happen with other renderers and/or Linux.

Normally, declaring highp as the default precision seems to "fix" these problems at the expense of compatibility with non-highp devices. However, the Lanczos3 shader displays a single color for the entire screen. This is true regardless of whether the highp hack is applied or not. @Splendide-Imaginarius even did some math to make the shader theoretically operate at mediump, but the result is still a single color on Vulkan+Windows.

It is unclear if ANGLE's Windows Vulkan is simply not operating to spec, or it is but most shaders in the wild just assume that mediump is silently operating as highp. I have run this test in mkxp-z, which seems to indicate that mediump is probably acting as mediump in the Vulkan setup, while any others are mediump acting as highp: https://webglfundamentals.org/webgl/lessons/webgl-qna-when-to-choose-highp--mediump--lowp-in-shaders.html

The GLES spec for precision:

Source: https://registry.khronos.org/OpenGL/specs/es/2.0/GLSL_ES_Specification_1.00.pdf

[Eblo]

It is unclear if ANGLE's Windows Vulkan is simply not operating to spec, or it is but most shaders in the wild just assume that mediump is silently operating as highp.

I've done extensive digging into this issue. The Vulkan-on-Windows implementation does adhere to spec; it is more strict than others. Other implementations are more lenient. Most shaders in the wild indeed do just assume mediump acts as highp, and/or that highp is available in fragment shaders. This is not an mkxp issue.