Crash on startup, fallback to OpenGL driver fails on older MacBook Pro when failing to find MoltenVK or Metal Vulkan driver

[lostminds]

Tested versions

Godot Engine v4.4.stable.official.4c311cbee

System information

macOS 14.7.4, MacBook Pro 2012, intel hd graphics 4000

Issue description

A user reports crashing at startup launching my exported Godot 4.4 app set to use the Mobile renderer.

Launching the binary from the command line to catch any startup errors this is what it reports:

Godot Engine v4.4.stable.official.4c311cbee - https://godotengine.org/
[mvk-error] VK_ERROR_INCOMPATIBLE_DRIVER: Vulkan is not supported on this device. MoltenVK requires Metal, which is not available on this device.
ERROR: Cannot find a compatible Vulkan installable client driver (ICD).
vkCreateInstance Failure
   at: _create_vulkan_instance (drivers/vulkan/rendering_context_driver_vulkan.cpp:900)
ERROR: Condition "err != OK" is true. Returning: err
   at: _initialize_instance (drivers/vulkan/rendering_context_driver_vulkan.cpp:735)
ERROR: Condition "err != OK" is true. Returning: err
   at: initialize (drivers/vulkan/rendering_context_driver_vulkan.cpp:931)
WARNING: Your device seem not to support MoltenVK or Metal, switching to OpenGL 3.
     at: DisplayServerMacOS (platform/macos/display_server_macos.mm:3820)
ERROR: Parameter "win.context" is null.
   at: create_context (platform/macos/gl_manager_macos_legacy.mm:57)
ERROR: Can't create an OpenGL context.
   at: _create_window (platform/macos/display_server_macos.mm:168)
ERROR: Condition "main_window == INVALID_WINDOW_ID" is true.
   at: DisplayServerMacOS (platform/macos/display_server_macos.mm:3879)
fish: Job 1, '/Applications/[APP NAME HERE]/C…' terminated by signal SIGSEGV (Address boundary error)

According to the user they are running macOS 14.7.4, which means they should have both Metal support and OpenGL support. This is however a little suspicious since these macbooks are listed as having either macOS 10.15 or macOS 13 as the last supported version. So it could be some custom hack here messing up the drivers.

But even if the hardware is too old for Metal or MoltenVK, it should definitely have support for OpenGL to run the fallback compatibility driver. But it looks like for some reason it's failing too while trying to fall back to OpenGL as well, failing to get a window context?

Steps to reproduce

Launch Godot 4.4 exported app using Mobile renderer on MacBook Pro 2012, intel hd graphics 4000, 16gb ram, macOS 14.7.4

Minimal reproduction project (MRP)

This should happen to any Godot 4.4 project run on this same hardware.

[Calinou]

• Related to Metal / MoltenVK fails initializing and leads to crash on macOS Sonoma (OpenCore) #95226.

According to the user they are running macOS 14.7.4, which means they should have both Metal support and OpenGL support. This is however a little suspicious since these macbooks are listed as having either macOS 10.15 or macOS 13 as the last supported version. So it could be some custom hack here messing up the drivers.

It's likely the user is using OpenCore to run a more recent version than what the Mac officially supports.

I'm not sure if Intel HD 4000 on macOS has ever supported OpenGL 3.3, or if it stopped at something like OpenGL 3.1.

[lostminds]

It's likely the user is using OpenCore to run a more recent version than what the Mac officially supports.

Yes, I asked about this and they confirmed this was the case. However, they also claimed an earlier build that used Godot 4.3 did work for them, so in this case it might be some other regression in 4.4. I've asked them to try again with an earlier 4.3 build to confirm and report back with the startup output to see if there are any errors in this case and it's just successful in falling back to OpenGL, or if it's actually getting the metal/vulkan driver.

[lostminds]

User confirmed that it actually didn't work using the vulkan/metal drivers in the 4.3 build either. However, in that version they were given a popup with the suggested terminal command to run it in compatibility mode, with did work for them (more or less, but that's another issue). However, at least the compatibility mode automatic fallback in 4.4 doesn't seem to work for them. I'll see if it's the same if they try to launch it using the extra launch arguments to launch in compatibility mode.

In a related question: Is there a way to force this falling back to compatibility mode on launch in testing from the editor? As in having the editor and project set to Mobile/Forward+ but then force the project on launch to fall back to compatibility as if the vulkan renderers weren't supported? Or is this the same as changing the project to compatibility mode and running? I have a suspicion that the latter might change some settings to avoid things that are incompatible/unsupported in compatibility mode, but that would still cause issues in the automatic fallback case when the project was built for another render pipeline.

[Calinou]

In a related question: Is there a way to force this falling back to compatibility mode on launch in testing from the editor? As in having the editor and project set to Mobile/Forward+ but then force the project on launch to fall back to compatibility as if the vulkan renderers weren't supported?

Yes, change the Main Run Args project setting to --rendering-method gl_compatibility. This will not actually call the fallback, but this will make the project run with Compatibility regardless of what it's configured to run to in the Project Settings. Alternatively, use a feature tag override for editor_runtime for the rendering method project setting.

[lostminds]

The user now got back to me, and launching the 4.4 build using the --rendering-method gl_compatibility launch arguments successfully launches and runs the projects seemingly with no problem. But without them the automatic fallback to compatibility seems to fail and cause the application to crash on launch as described above.

So, there seems to be some critical difference when it comes to initializing the compatibility renderer based on if this is set by launch arguments/project settings as the first choice or if it's used as a fallback after vulkan drivers fail.

[bruvzg]

The difference likely is MoltenVK version, and I think MoltenVK assumes device Metal capabilities only base on macOS version. Fallback likely won't work since MoltenVK will try to start and crash, fallback only triggers if specific renderer is completely unavailable.

[lostminds]

Fallback likely won't work since MoltenVK will try to start and crash, fallback only triggers if specific renderer is completely unavailable.

Could be, and that the MoltenVK crash is just delayed. But based on the error messages above it appears like the fallback process is at least started:

WARNING: Your device seem not to support MoltenVK or Metal, switching to OpenGL 3.
     at: DisplayServerMacOS (platform/macos/display_server_macos.mm:3820)
ERROR: Parameter "win.context" is null.
   at: create_context (platform/macos/gl_manager_macos_legacy.mm:57)
ERROR: Can't create an OpenGL context.
   at: _create_window (platform/macos/display_server_macos.mm:168)
ERROR: Condition "main_window == INVALID_WINDOW_ID" is true.
   at: DisplayServerMacOS (platform/macos/display_server_macos.mm:3879)

Before it finally crashes.

I realize this user group of macOS users using openCore are likely very small, so if it's just affecting them it might not be that big an issue. But I'm thinking it could indicating a more general issue that the fallback system is compromised somehow by the first render driver attempting but failing to initialize (leaving the window in some invalid state perhaps?), and that could be caused by other hardware/software configurations as well.

[ThunderFD]

Edit: as my crash is on windows I think it's unrelated to this issue, posting the same thing to issue 98848

I also have a user reporting something similar on windows (running on i3-3120M), the game crashes with the following log:

Godot Engine v4.4.1.stable.official.49a5bc7b6 - https://godotengine.org
WARNING: Your video card drivers seem not to support Vulkan, switching to Direct3D 12.
   at: DisplayServerWindows (platform/windows/display_server_windows.cpp:6831)
ERROR: D3D12CreateDevice failed with error 0x887a0004.
   at: _initialize_device (drivers/d3d12/rendering_device_driver_d3d12.cpp:6381)
ERROR: Condition "err != OK" is true. Returning: ERR_CANT_CREATE
   at: initialize (drivers/d3d12/rendering_device_driver_d3d12.cpp:6747)
ERROR: Failed to initialize driver for device.
   at: initialize (servers/rendering/rendering_device.cpp:6657)

But shouldn't the engine try to fall back to openGL after it tried d3d12? It doesn't seem to do this here, which differs from the logs above.

[amirtheswarann]

check my comment on #95226 ref