Option to disable (or enable) verbose/debug output

[tgurr]

Right now a lot of information is displayed when running an application making use of vkBasalt.

$ vkcube

vs.

$ ENABLE_VKBASALT=1 vkcube
/home/user/.config/vkBasalt/vkBasalt.conf
set option effects equal to monochrome
set option monochrome equal to /usr/share/vkBasalt/reshade-shaders/Shaders/Monochrome.fx
set option reshadeTexturePath equal to /usr/share/vkBasalt/reshade-shaders/Textures
set option reshadeIncludePath equal to /usr/share/vkBasalt/reshade-shaders/Shaders
interrupted create instance
found graphic capable queue
50 44
format 50
Interrupted create swapchain
Interrupted get swapchain images 0
Interrupted get swapchain images 3
fake image size: 1052692
fake image alignment: 4096
after createFakeSwapchainImages 
3swapchain images
current effectString monochrome
3 images in firstImages
using swapchain images as second images
3 images in secondImages
in creating ReshadeEffect 
after creating input ImageViews
after creating ImageViews
after creating shaderModule
Stencil Format: 129
after creating descriptorSetLayouts
after creating descriptorPool
after creating Pipeline layout
0
before allocating descriptor Sets
before writing descriptor Sets 
before writing descriptor Sets 
before writing descriptor Sets 
after writing ImageSamplerDescriptorSets

500 x 500
F__PostProcessVS
F__MonochromePass
finished creating Reshade effect
effect string count: 1
effect count: 2
after allocateCommandBuffer 3 for swapchain 0x56385118dba0
before applying effect 0x5638511921f0
applying ReshadeEffect0x563851197be0
after the first pipeline barrier
after binding image sampler
before beginn renderpass
after beginn renderpass
after bind pipeliene
after draw
after end renderpass
after the second pipeline barrier
before applying effect 0x563850bf35d0
before applying effect 0x5638511921f0
applying ReshadeEffect0x5638511ad960
after the first pipeline barrier
after binding image sampler
before beginn renderpass
after beginn renderpass
after bind pipeliene
after draw
after end renderpass
after the second pipeline barrier
before applying effect 0x563850bf35d0
before applying effect 0x5638511921f0
applying ReshadeEffect0x5638511a3300
after the first pipeline barrier
after binding image sampler
before beginn renderpass
after beginn renderpass
after bind pipeliene
after draw
after end renderpass
after the second pipeline barrier
before applying effect 0x563850bf35d0
after write CommandBuffer
after create semaphores
0writen commandbuffer0x563851197be0
1writen commandbuffer0x5638511ad960
2writen commandbuffer0x5638511a3300
after getswapchainimages

[mcoffin]

So, I was thinking about taking a pass at this, and cursory google'ing of "C++ logging frameworks" yielded quite mixed results.

Old suggestions seemed to indicate log4cxx as a viable option, but the project seems largely abandoned.

Just doing a lightweight custom solution with either environment variables or compile-time pre-processor directives is an option, and seemed preferrable until I thought about the users of this project.

Users here actually likely want to be able to configure logging backends to back with a file (to separate output from the actual application output), while still having the option to go straight to stdout if that is what they prefer.

I'd be willing to put in the grunt work to tackle this, after we have a discussion on what logging framework/strategy is likely best going forward.

I've seen Apache Mesos's usage of glog, and while it's not perfect, it might be good enough for our use case.

Regardless, especially if you're primarily a C++ developer (I've been more Rust-focused in this space when possible), particularly for a library used by other applications, please chime in on your experiences with logging frameworks, and what you think might offer a good solution going forward.

To be honest, given the non-transparent-in-logs way that vulkan-icd-loader loads layers, I think that adding a dynamically-linked logging framework dependency is probably not the way to go. We don't want users who don't have a dynamic library available invisibly having nothing happen with the layer, since that's a bad experience.

In summary, my opinion is that a good logging framework/strategy solution here would meet the following criteria.

1. Ability to control "levels" of logging
2. Able to be configured via either vkBasalt.conf or environment variables, without another config file for the logging framework.
3. Statically linked, or at least in some way not requiring any runtime dependencies to be installed by the end user.
4. (more optional than other things on this list) Ability to configure different logging backends, to either dump to a file, or journalctl logs from systemd, or just plain stdout, etc.
5. (even more optional) Ability to have 0-cost logging levels at compile time. (i.e., if the user doesn't compile with debug or trace log levels, then those log messages should be 0-cost at runtime. While this usually won't matter, it could impact performance for workloads that make heavier or more frequent use of the functions interrupted by the vkbasalt layer that output logging information.

Let me know your thoughts, and I'll give this one a go, despite it being a lot of boring find/replace boilerplate work.

[mcoffin]

Further investigation yielded that gabime/spdlog might be a good option as well.

[DadSchoorse]

https://github.com/DadSchoorse/vkBasalt#debug-output