Open christophe-lunarg opened 1 week ago
Yep, this is an oversight in the implementation. When the loader settings file doesn't have a stderr_log field, the "debug_level" is left at the default zero value. Buuut when logging the loader would not bother checking VK_LOADER_DEBUG at all if the settings file was active, irregardless of the settings. It is a simple one line fix to make the log function require that the settings file debug level is 'non-zero' (set to something) before using that as the filter. (and the fix will be pushed up in the extended_loader_settings_tests branch shortly)
I do think it may be beneficial to have the log messages be filtered by the union of the VK_LOADER_DEBUG and loader settings file stderr_log output. The current logic means that a user who opened vkconfig & set some filters may not know that those filters are what will be used. They then may try to set VK_LOADER_DEBUG and see no change in behavior. This is more of an edge case & learning curve than a pure problem. But I raise it to get your opinion.
Yep, this is an oversight in the implementation. When the loader settings file doesn't have a stderr_log field, the "debug_level" is left at the default zero value. Buuut when logging the loader would not bother checking VK_LOADER_DEBUG at all if the settings file was active, irregardless of the settings. It is a simple one line fix to make the log function require that the settings file debug level is 'non-zero' (set to something) before using that as the filter. (and the fix will be pushed up in the extended_loader_settings_tests branch shortly)
I think this is plently already, no need to have a union mode specifcally because I don't think "The current logic means that a user who opened vkconfig & set some filters may not know that those filters are what will be used. They then may try to set VK_LOADER_DEBUG
and see no change in behavior." is true. If the user know about VK_LOADER_DEBUG, the user will know about Vulkan Configurator equivalent as it's really a direct mapping.
And a union would imply that if VK_LOADER_DEBUG
is set to all and the user want to disable the loader message maybe to have a shorter log to find something specific, that use case won't work.
If you add something that enables to switch between both mode in vk_loader_settings.json, then why not,
This issue still reproduce with today build of Vulkan Loader main branch
I would expect to be able to control logging with
VK_LOADER_DEBUG=all
when not using thestderr_log
section invk_loader_settings.json
, a bit like I can control layers withVK_LOADER_LAYERS_ENABLE
when there are not invk_loader_settings.json
.However, when using the Vulkan Loader settings WITHOUT "stderr_log" section but using
VK_LOADER_DEBUG=all
I am getting the following log which is pretty short: vk_loader_settings.jsonvk_loader_settings.json When using
stderr_log
with all the log type I am getting a very exhautive log: