Vulkan: 3D editor grid lines render incorrectly on macOS Apple Silicon GPU

[Altobanor]

Godot version

v4.2.beta4.official [93cdacb]

System information

macOS Ventura 13.2.1, Apple M1 Pro

Issue description

I opened a freshly created project and noticed a visual anomaly in the 3D workspace. It is present no matter what view you choose.

Steps to reproduce

Created multiple new projects and in all cases, the anomaly remained. This did not show up in the 4.1.2 Stable version.

Minimal reproduction project

N/A

[akien-mga]

I believe your Godot version is haunted. 👻🎃

[Altobanor]

LOL! You just might be right!

[Calinou]

I can't reproduce this on 4.2.beta 6afd320 (Linux, GeForce RTX 4090) with any rendering methods.

Which rendering method are you using in the project? If you have access to other hardware, can you reproduce it there too?

Also, can you reproduce this in earlier 4.2 dev and beta builds? You can download them here.

[Altobanor]

After further testing, it doesn't appear in Render: "Compatibility". It does appear in "Forward+" and "Mobile". I am on a Mac Book Pro, Apple M1 Pro CPU. My rendering device driver is vulkan. I can't change it to anything else.

[mrbbbaixue]

Can confirm it reproduces on Apple Mac Mini (M1 2020) with Godot 4.2beta4 Vulkan renderer.

[Calinou]

@mrbbbaixue Can you reproduce this in earlier 4.2 dev and beta builds? You can download them here.

[mrbbbaixue]

@mrbbbaixue Can you reproduce this in earlier 4.2 dev and beta builds? You can download them here.

@Calinou I'm a bit lucky today, only testing twice to find out when this bug was introduced: gird rendering is still normal in 4.2 dev6, but the issue appeared in 4.2 beta1. I think it’s one of the PRs between these two that broke it.

[clayjohn]

I suspect this is the same issue as #83667 and has to do with how we encode normals.

The grid drawing shader uses normals to fade out grid layers when zooming in and out. If the normals are corrupted, then the fading gets broken as well.

Fixing this issue and #83667 will likely require us finding a workaround for something that is unsupported on M1 macs. That will be difficult to do as I do not own an M1 mac

[clayjohn]

Actually I have a theory. Pluxy on Rocketchat posted the following validation warning:

drivers/vulkan/vulkan_context.cpp:267 - VALIDATION - Message Id Number: 0 | Message Id Name: 
      VK_SUCCESS: Found attribute with size (8) larger than it's binding's stride (4). Changing descriptor format from MTLVertexFormatUShort4Normalized to MTLVertexFormatUShort2Normalized.
      Objects - 1
          Object[0] - VK_OBJECT_TYPE_PIPELINE, Handle 11534070784

Which seems to indicate that Metal doesn't allow us to use an attribute with a size longer than its stride (which we need to do in order for normals to work correctly. This is something that is supported by Vulkan and D3d12, so it is surprising that it is causing issues on Metal

Edit: Confirmed, MoltenVK is changing our vertex format because it isn't support by metal (https://github.com/KhronosGroup/MoltenVK/blob/bb914faa533a3ed923abf9cce3f9702492bfaef0/MoltenVK/MoltenVK/GPUObjects/MVKPipeline.mm#L1454-L1455). We are going to have to make an apple-specific workaround