Forward+ and Mobile Renderers Graphical Glitches on Intel Haswell IGP

[MBCX]

Godot version

v4.2.dev.custom_build [bfd78bb91]

System information

Godot v4.2.dev (bfd78bb91) - Zorin OS 16.3 - X11 - GLES3 (Compatibility) - Mesa DRI Intel(R) HD Graphics 4400 (HSW GT2) () - Intel(R) Core(TM) i5-4310U CPU @ 2.00GHz (4 Threads)

Issue description

I was testing one of the official Godot 4 demos, specifically the 3D AI navigation project on my Linux Laptop. And this is what I was greeted with (flashing colours warning):

With the Vulkan Renderer:

And the Mobile Renderer, is so much worse:

Playing the game also brings the same graphical errors:

The compatibility mode is absolutely fine. Am I missing something? Or maybe (most likely) my laptop is just not compatible with Vulkan.

Steps to reproduce

Not recommended but:

1. Open a 3d godot demo project, and make sure to use Vulkan and/or Mobile Renderers.
2. Wait for it to load.

Minimal reproduction project

3d-navigation.zip

[Calinou]

Mesa DRI Intel(R) HD Graphics 4400 (

Intel Haswell IGPs don't have full Vulkan support due to hardware limitations (not even 1.0). They happen to work on Linux because Mesa has worked on a limited implementation, but it's not full-featured enough to run production apps that use Vulkan. On Windows, it won't work at all as Intel's Windows driver team has never worked on a Vulkan implementation there.

As a result, if you run any Vulkan application from a terminal, you will be greeted with a message of the form:

Not a conformant Vulkan implementation, testing use only.

We should probably mandate Vulkan 1.1 instead (perhaps 1.2 on desktop and 1.1 on mobile), as this will also exclude a lot of Android devices that claim to have Vulkan support while it's actually nonexistent for anything more than vkcube.

[MBCX]

Yeah, I ran godot from the console and I saw a similar message.

[Calinou]

Interestingly, these claim to have Vulkan 1.2 support, so requiring Vulkan 1.2 will not prevent Intel Haswell IGPs from running Godot's Vulkan renderers (and falling back to OpenGL once that fallback is implemented).

We probably need to do something more elaborate such as detecting the model name as early as possible.

[darksylinc]

Does the problem go away when you disable MSAA on Vulkan?

[MBCX]

@darksylinc Yes it does! Changing it from default (4x) to disabled worked for both Forward+ as well as Mobile.

The graphic glitches are gone for the game, as well as the editor.

[Calinou]

In this case, it shouldn't be as difficult to force disabling MSAA when a Haswell IGP is detected. This can be done at runtime when the context is already created.

Could you check whether these Environment properties are functional in Forward+?

• SSAO
• SDFGI
• SSIL
• Glow
• Volumetric fog

[MBCX]

Here are the results in my test in Forward+ running the game.

SSAO at ultra (custom)

SDFGI with default settings and SSAO at ultra. The difference is not very noticeable.

So far, no graphical glitches for the game or the editor. Although as expected, it lags heavily on my laptop when I run the game.

SSIL with SSAO quality to default (medium)

Volumetric Fog with default settings

And lastly, default glow worked fine. With the default settings it didn't look any different from the first ones above.

[darksylinc]

This is a duplicate of #81060 then.

In this case, it shouldn't be as difficult to force disabling MSAA when a Haswell IGP is detected. This can be done at runtime when the context is already created.

@Calinou it's not about disabling MSAA on HSW, it's about MSAA being broken.

Perhaps it would be prudent to disable MSAA until it is resolved? We're gonna keep getting reports that Godot is broken on random GPUs when the culprit is our handling of MSAA.

[Calinou]

Perhaps it would be prudent to disable MSAA until it is resolved?

Modern AMD/NVIDIA GPUs seem to handle this invalid Vulkan usage well so far (in the sense that there are no visible bugs), which is why I was suggesting to disable MSAA only on problematic GPUs (AMD Polaris, old Intel IGPs, Android).

Being able to use MSAA is a selling point of Godot's Forward+/Mobile renderer, so I would rather not have it go away entirely, even if it's temporary.

[darksylinc]

I spoke to Clay about this, it's better if we just fix the MSAA problem even if the solution is far from ideal.