Defferred initialization

[pchome]

Maybe entry points are not the best places to init some internal stuff. Because every damn thing requesting vulkan also triggering Config constructor.

This causes:

• spam in the log output/file
• multiple file operations which can (at some point) burn a hole in users config file (jk)

Effects should "play dead" as long as possible. This is how the trace log looks like after I moved Config creation into vkCreateSwapchainKHR:

[entries before an actual action] (click to view)

...
vkBasalt trace: vkCreateInstance
vkBasalt trace: vkDestroyInstance
vkBasalt trace: vkCreateInstance
vkBasalt trace: vkDestroyInstance
vkBasalt trace: vkCreateInstance
vkBasalt trace: vkDestroyInstance
vkBasalt trace: vkCreateInstance
vkBasalt trace: vkDestroyInstance
vkBasalt trace: vkCreateInstance
vkBasalt trace: vkDestroyInstance
vkBasalt trace: vkCreateInstance
vkBasalt trace: vkCreateDevice
vkBasalt debug: device supports VK_KHR_swapchain_mutable_format
vkBasalt debug: activating mutable_format
vkBasalt trace: vkGetDeviceQueue
vkBasalt debug: found graphic capable queue
vkBasalt trace: vkGetDeviceQueue
vkBasalt trace: vkDestroyDevice
vkBasalt debug: DestroyCommandPool
vkBasalt trace: vkDestroyInstance
...

^ here will be the final create and everything else.

Imagine configuration output after every vkBasalt trace: vkCreateInstance (how it currently is), also some applications can be even more "evil".

Well, vkCreateSwapchainKHR not the best place too, maybe you know better solution.

[DadSchoorse]

The problem is that the config is needed in vkGetDeviceProcAddr (and maybe even vkGetInstanceProcAddr but I'm not 100% sure) to check if we need to intercept more functions for depth capturing.

[pchome]

IDK, maybe replace this check with getenv(VKBASALT_EXPERIMENTAL) ; or just report them unconditionally, and then check inside if you need to do additional stuff; idk...