A wise man once said to me “Reboot early, and often!” He said it many times actually. When you’re trying to troubleshoot programs for which you don’t have the source code, you tend to develop little rituals that you go through to “fix” them…
So here I was today, trying to power through the boilerplate to draw a triangle in Vulkan. I had just finished up creating my Pipeline object, and ran my program to see if it worked. As you can imagine, it didn’t work.
Shockingly, C++ Causes Problems
First up: my shaders are invalid. The error:
validation layer: ObjectTracker : Invalid Shader Module Object 0xa.
Of course, the Object Tracker layer is there to tell you when you try to use objects that are not valid handles. Usually this is because
vKcreateFoo did not return
VK_SUCCESS. Of course,
vkCreateShaderModule definitely did return
VK_SUCCESS, because if it hadn’t my program would have died in a fire thanks to my
expect assertion macro. Surely either I have a driver bug or C++ is doing “exactly what I told it to.”
So I do some troubleshooting. I upgrade my driver which does nothing. Then I examine my code. Buried in a comment thread on this stackoverflow question is the suggestion that a destructor is being called. I examine my code, and sure enough, the RAII object that I’m storing my shader in is being destructed before the call to
vkCreateGraphicsPipeline. C++ was doing “exactly what I told it to.”
So an hour later, and one problem down. I recompile and try again:
vkEnumeratePhysicalDevices: returned VK_ERROR_INITIALIZATION_FAILED, indicating that initialization of an object has failed
Shenanigans! There’s no way that
vkEnumeratePhysicalDevices is messed up, that’s been working for weeks! I turn to the Googler, but to no avail. Then the words rang in my head “Reboot early and often!” It’s not like I just updated my graphics driver without rebooting or anything… Oh wait!
Moral of the story: reboot early, and often!