Day 3 (Dec 13, 2020) ~~~ Layers Upon Layers of Validation Layers - kwilson33/learning-vulkan GitHub Wiki
Progress Today
I made it through this page today of the official Vulkan tutorial.
Here are some major takeaways
1. Validation layers are pretty confusing. It wasn't until I got into *message callbacks that I realized how deep they went. There is a lot that goes into getting them working, but they are very useful.
This is a method used for callbacks (which you can handle yourselves in Vulkan so the messages don't go just to stdout). Each of the input parameters can be many values themselves.
static VKAPI_ATTR VkBool32 VKAPI_CALL debugCallback(
VkDebugUtilsMessageSeverityFlagBitsEXT messageSeverity,
VkDebugUtilsMessageTypeFlagsEXT messageType,
const VkDebugUtilsMessengerCallbackDataEXT* pCallbackData,
void* pUserData) {
std::cerr << "validation layer: " << pCallbackData->pMessage << std::endl;
return VK_FALSE;
}
For example, the messageSeverity
parameter of type VkDebugUtilsMessageSeverityFlagBitsEXT
can be:
VK_DEBUG_UTILS_MESSAGE_SEVERITY_VERBOSE_BIT_EXT
: Diagnostic messageVK_DEBUG_UTILS_MESSAGE_SEVERITY_INFO_BIT_EXT
: Informational message like the creation of a resourceVK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXT
: Message about behavior that is not necessarily an error, but very likely a bug in your applicationVK_DEBUG_UTILS_MESSAGE_SEVERITY_ERROR_BIT_EXT
: Message about behavior that is invalid and may cause crashes
It's pretty cool though, because the way these values are setup allows for using comparisons to check like
if (messageSeverity >= VK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXT) {
// Message is important enough to show
}
To get this callback method to work, you have to explicitly tell Vulkan about it.
VkDebugUtilsMessengerEXT debugMessenger;
It definitely wasn't an understatement when I heard Vulkan was very verbose...
2. Small progress feels good! All I got done today was getting validation layers and message callbacks to work, and that's not super exciting Computer Graphics stuff, but at the end of it I was able to see that everything worked. I know the more I keep pushing the forward the closer I get to actually drawing something to my screen.
3. Summary of what I've learned about validation layers and why they're necessary for Vulkan programming.
- Simple mistakes like setting a required Vulkan parameter to a nullptr is not explicitly handled and will just result in crashes or undefined behavior.
- Vulkan has a system for introducing checks into the API called validation layers. They are optional components that hook into Vulkan function calls to apply additional operations.
- Common operations in validation layers are:
- Checking the values of parameters against the specifications.
- Checking creation and destruction of objects.
- Checking thread safety.
- Common operations in validation layers are:
- Validation layers will print debug messages to stdout by default, but you can handle them yourselves by providing an explicit call callback in your program (message callback)
- This allows you to decide what kind of messages you would like to see, because not all are fatal errors.
- Setting these up takes a long time compared to everything else I've done so far.
See ya!
So, that's it for today. Third day of learning Vulkan. The validation layers tutorial took longer than expected, there was just so much to do to get it working, like having to explicitly load Vulkan functions into my program using proxy functions... something I've never had to do before for anything else. At the end of that tutorial I was able to see that not correctly deleting a Vulkan instance correctly creates a message callback that shows up in the console, as shown below.
validation layer: Validation Error: [ VUID-vkDestroyInstance-instance-00629 ] Object 0: handle = 0x1c1226e5df0, type = VK_OBJECT_TYPE_INSTANCE; Object 1: handle = 0x2aefa40000000001, type = VK_OBJECT_TYPE_DEBUG_UTILS_MESSENGER_EXT; | MessageID = 0x8b3d8e18 | OBJ ERROR : For VkInstance 0x1c1226e5df0[], VkDebugUtilsMessengerEXT 0x2aefa40000000001[] has not been destroyed. The Vulkan spec states: All child objects created using instance must have been destroyed prior to destroying instance (https://vulkan.lunarg.com/doc/view/1.2.154.1/windows/1.2-extensions/vkspec.html#VUID-vkDestroyInstance-instance-00629)
validation layer: Validation Error: [ VUID-vkDestroyInstance-instance-00629 ] Object 0: handle = 0x1c1226e5df0, type = VK_OBJECT_TYPE_INSTANCE; Object 1: handle = 0x2aefa40000000001, type = VK_OBJECT_TYPE_DEBUG_UTILS_MESSENGER_EXT; | MessageID = 0x8b3d8e18 | OBJ ERROR : For VkInstance 0x1c1226e5df0[], VkDebugUtilsMessengerEXT 0x2aefa40000000001[] has not been destroyed. The Vulkan spec states: All child objects created using instance must have been destroyed prior to destroying instance (https://vulkan.lunarg.com/doc/view/1.2.154.1/windows/1.2-extensions/vkspec.html#VUID-vkDestroyInstance-instance-00629)