Comments (13)
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.
from vulkan-loader.
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.
from vulkan-loader.
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!
from vulkan-loader.
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:
- Enable
INFO
andDEBUG
and sift through several pages of unrelated information. Then unenable it again. - Break something on purpose, then unbreak it again. (Doesn't give extended info -- like version.)
- Permanently enable
INFO
andDEBUG
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).
from vulkan-loader.
@karl-lunarg I already listed use cases in the previous post, but mainly:
- In release mode I want to be sure I am not running validation layers.
- 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). - 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.
from vulkan-loader.
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.
from vulkan-loader.
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
).
from vulkan-loader.
@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.
from vulkan-loader.
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.
from vulkan-loader.
@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.
from vulkan-loader.
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.
from vulkan-loader.
I didn't say loader needs to do anything. The Issue just got migrated here for some reason...
from vulkan-loader.
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.
from vulkan-loader.
Related Issues (20)
- VK_LOADER_DEBUG should report actual library loaded, not library attempted HOT 2
- Crash because of unload_drivers_without_physical_devices() HOT 6
- Vulkan-ICD-Loader update causes all games to crash HOT 3
- Build failing on 32 bit Windows because of some pointer-to-integer size mismatch HOT 6
- dEQP-VK.api.object_management.multithreaded_per_thread_resources.device_group crash HOT 8
- Add support for env variables inside JSON manifests HOT 4
- vkGetInstanceProcAddr returns non-NULL for unsupported functions HOT 21
- Can a VK_ extension be disabled with env vars? HOT 7
- allow GAS on MinGW HOT 2
- Vulkan HOT 2
- Unable to build Vulkan Loader from source HOT 4
- Downstream packaging best practices in combination with Vulkan-Headers HOT 5
- Failure in one ICD causes total failure of vkEnumeratePhysicalDevices HOT 3
- Calling `vkGetInstanceProcAddr(NULL, "vkEnumerateInstanceExtensionProperties")` from within a layer returns a NULL value HOT 3
- Segmentation fault at `loader_icd_destroy` on linux HOT 3
- vkEnumerateInstanceExtensionProperties is incorrectly implemented HOT 5
- Mismatched calloc/free in vkEnumeratePhysicalDevices when using custom VkAllocationCallbacks HOT 5
- Fullscreen-Vulkan-wayland windows flicker for absolutely no reasons sometimes HOT 5
- What is the recommended way for a layer to hide extensions? HOT 1
- Vulkan Loader settings is looking for registry key Software\\Khronos\\Vulkan\\Settings but that's the layer settings location HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vulkan-loader.