This PR will be done here, so it will be closed.
Given the ContextVK relationship, should this DebugUtils be a member of VKDevice?
The OpenGL test increments the vertex buffer attribute length, causing a subsequent Vulkan test to run-time check failure #2.
I added it because an error occurred in the build of windows. I don't know if it's the best.
This break is as a chain on the device. It has no direct relationship with VKContext.
Regarding the labeling function of vk_ext_debug_utils, it seems that it does not depend on VK_VALIDATION_LAYER.
Please run make format when push and configure clang-format to your IDE. This file has several issues where it doesn't match our code style.
Current vulkan is 1.3 and blender locks the version to 1.2. There are situations where it cannot be said that conflicts regarding extensions will not occur, so I think that VK_LAYER_PATH should…
What we check with enableLayer is not whether it's actually ready for dynamic linking.
If you return when ev_val is nullptr, you can't print the warnings. It will check if there is no VK_LAYER_PATH and if there is no json file, so it will not return early.
In order for developers to use the validation layer, we will use vulkanSDK, but first I would like to make a PR about how to load it. In particular we have to decide whether to do it Explicit or Implicit. Do you have an opinion on this point?
There is no direct relationship between VK_LAYER_KHRONOS_validation being enabled and error(VkResult) handling for vulkan functions.