Loader should issue informational message when loading each layer

[karl-lunarg]

In order to provide run-time confirmation of layer configuration, the loader should emit an INFO message for each layer loaded, including at least name and path.

@krOoze -- What in addition is needed to meet your use cases below?

Moved to loader as it doesn't abuse the VK_DEBUG_REPORT_PERFORMANCE_WARNING_BIT_EXT, and addresses the required use cases below

Issue by krOoze (MIGRATED)
Wednesday Nov 15, 2017 at 16:14 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2207

Original Text:

Enabled validation layers should give performance warning.

The primary motivation is that I would want a feedback from the implementation, that I enabled the layers properly and my validation environment works. The message could be something like:

Enabling validation layers: [ordered list of layers or the standard_validation] [version] [path] [Debug|Release] {for the duration of vkCreateInstance and vkDestroyInstance}. Receiving messages [debug callback flags]. This will likely have negative performance impact.

The reason for using VK_DEBUG_REPORT_PERFORMANCE_WARNING_BIT_EXT is because it technically is a performance drain. (And it is simpler to have this enabled, otherwise it could be INFO, but that would require filtering out all the other unwanted INFO messages.)

It probably have to be logged twice if the user uses both the temporary and regular debug callback. It is a stretch though to pass the temporary callback as a PERFORMANCE_WARNING...

[karl-lunarg]

Comment by mark-lunarg (MIGRATED)
Wednesday Nov 15, 2017 at 16:39 GMT

---

@krOoze, there is already a facility in the loader for something close to this -- you can set
"VK_LOADER_DEBUG=all" in your environment and it will provide some of the information you want.

One minor issue related to spitting out a perf-warning with the above message is that each of the layers is independent and shares no data, so each layer would have to output its own message.

[karl-lunarg]

Comment by krOoze (MIGRATED)
Wednesday Nov 15, 2017 at 16:53 GMT

---

@mark-lunarg That just seems to register another callback with all flags enabled.

[karl-lunarg]

Comment by mark-lunarg (MIGRATED)
Wednesday Nov 15, 2017 at 20:39 GMT

---

Hi again, we talked about it here and were hoping to get a better idea about which problem(s) you are hoping to solve, taking into account that the loader debug environment setting does indicate which layers are loaded. We're open to the suggestion but need to justify the effort. Thanks!

[karl-lunarg]

Comment by krOoze (MIGRATED)
Wednesday Nov 15, 2017 at 21:02 GMT

---

Use cases:

• if I run an app I don't know if it is just perfect, or if the layers are simply not working.
• if I switch between layer versions (e.g. release vs debug, or SDK vs master branch) I want to know which I am currently using
• I want to know, if I have layers enabled by accident (let's say I accidentally enable layers in persistent environment variables)
• If I am running on some subset of the layers, or using them in some weird order, I also want to immediatelly know

Currenty I have the options:

1. Enable INFO and DEBUG and sift through several pages of unrelated information. Then unenable it again.
2. Break something on purpose, then unbreak it again. (Doesn't give extended info -- like version.)
3. Permanently enable INFO and DEBUG and filter the messages manually. (Can't do with environment variable enabled layers)

Those options sound inadequate for something as this that should be simple. -> the suggestion above to make an intro VK_DEBUG_REPORT_PERFORMANCE_WARNING_BIT_EXT message. It abuses a bit the fact that it is in fact a performance matter, and at the same time makes it easier to get the desired feedback (that layers work).

[krOoze]

@karl-lunarg I already listed use cases in the previous post, but mainly:

1. In release mode I want to be sure I am not running validation layers.
2. In debug mode I want to be sure I am running validation layers (and they work correctly, and I use all of them; i.e. standard_validation meta-layer).
3. As a developer here, I want to be sure I am currently using master, and not the SDK layers.

nr. 1 somewhat implies it should be VK_DEBUG_REPORT_PERFORMANCE_WARNING_BIT_EXT, and it is not even really abuse; the layers do use extra unnecessary resources. Regular layers could be INFO though...

Though I guess not an end of the world if it is INFO. One would have to register separate messanger and filter the message out by some identifier (so at least add well documented message id, I guess). Though my hope is new users asking for help would copy-paste this warning, without the community having to ask each time whether they have layers enabled.

But yea, name + path (all are same path usually, so could be there only once). Preferrably in single summary PERFORMANCE_WARNING message, when they are enabled.

Oh, and version. That is useful to spot outdated SDK, when helping others.
And if they were enabled by environment or programmatically. Maybe also the layer settings when using the non-programmatic enabling scheme.

[MarkY-LunarG]

Now, set VK_LOADER_DEBUG=layer and you should get information like:

Application
 ||
Loader
 ||
Layer 1
 || 
Layer 2
 ||
Implementations

Of course, it should show no layers if none are enabled. I hope this satisfies your needs.

This information should also be outputted when VK_LOADER_DEBUG=all, but that's kind of messy and overwhelming.

My problem with associating this with PERFORMANCE_WARNING is that there are layers that are always enabled. The various GPU sorting layers by the IHVs for example. So you would always get this message. I'd prefer to keep it something like this. I'm willing to make it show up for both, though, if it's important enough.

[MarkY-LunarG]

I also now output more information. For each layer I output:

• If the layer is implicit or explicit
• If the layer is implicit, what is the disable environment variable to disable it
• Where the manifest file is located
• What library is being loaded for that layer.

This is all enabled with VK_LOADER_DEBUG=layer (or all).

[krOoze]

@MarkY-LunarG The solution is kinda not in the spirit of why it is needed. My intention here is not to debug the loader (as the enabling mechanism would suggest). My intention here is to know whether the app is (or isn't) in debug mode, an preferrably in as foolproof and implicit way as possible.

I care about virtually none of the above layer information. Regardless, now that we touched on it, that is perhaps information that should be available programatically and through vulkaninfo and not through some obscure env variable.

[MarkY-LunarG]

Yeah, the concern is how do you define "debug mode" for an application? Enabling validation layers, using a debug loader, forcing VK_LAYER_PATH/VK_ICD_FILENAMES. All of that could be considered debug mode. My concern is that's really vague and hard to track. I've re-opened this for now so we can think about it some more, though. Maybe we can think of something.

[krOoze]

@MarkY-LunarG It's not that vague. If at least VK_LAYER_KHRONOS_validation announced itself with non-INFO message, it would be fine enough.

using a debug loader

That too perhaps, but it is diminishing returns. Less people use debug build of loader.

forcing VK_LAYER_PATH/VK_ICD_FILENAMES

Perhaps useful, but for diferent and nicher reasons.

[MarkY-LunarG]

This is actually handled by the EXT_tooling_info extension. I worry that making the loader have to query information about every layer could be an issue and trying to track which ones are "debug" could be too much work on something that's not supposed to be too invasive.

[krOoze]

I didn't say loader needs to do anything. The Issue just got migrated here for some reason...

[charles-lunarg]

I think tooling info extension solves this gap pretty well. I will close this issue, feel free to reopen it, or ask to move it to a better location if you feel this is in err.