loader: Change incompatible driver warning to debug level

[akien-mga]

Some Linux distros (at least Fedora 44) ship Mesa's Dozen driver, even though it's not compatible as is on Linux.

So the loader would systematically warn about it, and Vulkan application users are confused by the message:

terminator_CreateInstance: Received return code -9 from call to vkCreateInstance in ICD /usr/lib64/libvulkan_dzn.so. Skipping this driver.

Some additional context:

• Godot PR silencing this warning at application level: Vulkan: Silence loader warning about incompatible drivers godotengine/godot#120393
  • That's sufficient for Godot, but I think it's a loader issue to warn about something users shouldn't worry about it, hence this suggestion.
• @airlied seemed to run into this too and changed the return code for Dozen from VK_ERROR_INITIALIZATION_FAILED to VK_ERROR_INCOMPATIBLE_DRIVER in Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38611
  • I was hoping this would silence the warning but it seems it doesn't as of Mesa 26.0.8 in Fedora 44.
• I don't claim the change I propose is the best approach, either functionally or style wise. Feel free to suggest changes / make a different change, or outright reject if you don't think this should be changed. Some other options would be to use VULKAN_LOADER_INFO_BIT instead of DEBUG (Godot ignores both so that's good for me) and/or to write a custom message that's more intelligible now that VK_ERROR_INCOMPATIBLE_DRIVER is special-cased.
• I tested this change on top of v1.4.341, as that's the version of vulkan-headers I had packaged on Fedora 44, so it was more convenient. I expect it to work fine on main too.
• No AI was used in making this change or writing this description.

[ci-tester-lunarg]

Author akien-mga not on autobuild list. Waiting for curator authorization before starting CI build.

[ci-tester-lunarg]

Author akien-mga not on autobuild list. Waiting for curator authorization before starting CI build.

[CLAassistant]

All committers have signed the CLA.

[ci-tester-lunarg]

Author akien-mga not on autobuild list. Waiting for curator authorization before starting CI build.

[ci-tester-lunarg]

Author akien-mga not on autobuild list. Waiting for curator authorization before starting CI build.

[akien-mga]

I put this in a local variable as it was tricky otherwise to keep clang-format happy, the line would be slightly too long and it would throw 0, to its own line, which doesn't match the style used elsewhere.

Alternatively, this could be:

            loader_log(ptr_instance,
                       VK_ERROR_INCOMPATIBLE_DRIVER == icd_result ? VULKAN_LOADER_DEBUG_BIT : VULKAN_LOADER_WARN_BIT,
                       0,
                       "terminator_CreateInstance: Received return code %i from call to vkCreateInstance in ICD %s. Skipping "
                       "this driver.",
                       icd_result, icd_term->scanned_icd->lib_name);

[charles-lunarg]

This is a very crude fix because it downgrades error codes, the API mechanism for drivers to signal issues, from a user visible WARN to a often ignored INFO. Future issues with other drivers will be ignored as INFO level. Changing the error code from INCOMPATIBLE_DRIVER to INITIALIZATION_FAILED still means that the driver does nothing.

The ultimate fix is to get distro's to not ship dozen. Fixing the problem at its source after all. It seems like dozen returns an error if it cannot satisfy some conditions upon initialization. A way to fix it without causing this error message would be for dozen to succeed vkCreateInstance, then return 0 physical devices. That would signal "hey, you loaded me but there is nothing useful for you here".

There are existing environment variables in the loader that should help this. VK_LOADER_DRIVERS_DISABLE=*dozen* should prevent the dozen driver from loading at all.
I can't promise it works perfectly, as I didn't test it. The filter name might need changing, and there may be undesired log messages from setting that env-var.

[akien-mga]

Thanks for the feedback. That makes sense.

The ultimate fix is to get distro's to not ship dozen. Fixing the problem at its source after all.

I'm not familiar with the reasons why Fedora and maybe other distros ship dozen, but I suspect this is intentional. The spec file includes explicit conditionals for enabling D3D12: https://src.fedoraproject.org/rpms/mesa/blob/rawhide/f/mesa.spec
I suspect this is meant for using Fedora as a WSL distro on Windows.

It seems like dozen returns an error if it cannot satisfy some conditions upon initialization. A way to fix it without causing this error message would be for dozen to succeed vkCreateInstance, then return 0 physical devices. That would signal "hey, you loaded me but there is nothing useful for you here".

Right, I'm not deeply familiar with how other drivers are implemented but I suspect that other drivers which aren't compatible with my system handle it different from dozen, as they don't trigger this warning. E.g. asahi_icd.x86_64.json, freedreno_icd.x86_64.json, or nouveau_icd.x86_64.json.

I can open a Mesa issue to discuss this further.
WDYT @airlied?

---

Closing the PR as it's not a proper solution.

[airlied]

this should be fixed in mesa, not by not shipping dozen, but by fixing dozen to return the incompatible driver error code when it fails to find it's requirements.

[airlied]

but it does appear to be returning INCOMPATIBLE_DRIVER which I thought was the correct thing to return to not print a warning

[airlied]

if it should just fail to enumerate anything then we should probably just fix that in dozen, so file a mesa issue anyways

[akien-mga]

if it should just fail to enumerate anything then we should probably just fix that in dozen, so file a mesa issue anyways

Done: mesa/mesa#15699