Move destroyInstance to Base level
Suggestion move destroyInstance to Base level, move destroyDevice to Instance level
const instance_handle = try vkb.createInstance(&create_info, null);
// If load Instance proc failed, no chance to destroy instance
const vki = try proc.loadInstance(instance_handle, vkb.dispatch.vkGetInstanceProcAddr);
errdefer vki.destroyInstance(instance_handle, null);
destroyDevice is the same
const device_handle = try self.vki.createDevice(self.physical_devices[0], &p_create_info, null);
// If load Device proc failed, no chance to destroy device
const vkd = try proc.loadDevice(device_handle, vki.dispatch.vkGetDeviceProcAddr);
errdefer vkd.destroyDevice(device_handle, null);
Yes this annoying, but it does make sense: the instance destructor is specific to one type of instance, so it's depended on the load. To be clear, this is a Vulkan thing and not something that I can really change.
If you want to deal with it, you can catch and use a dedicated wrapper that only had the destroy function. If that also fails youre out of luck i guess. Personally i suggest to leak it: the OS will clean things up for you anyway.
Yes this annoying, but it does make sense: the instance destructor is specific to one type of instance, so it's depended on the load. To be clear, this is a Vulkan thing and not something that I can really change.
If you want to deal with it, you can catch and use a dedicated wrapper that only had the destroy function. If that also fails youre out of luck i guess. Personally i suggest to leak it: the OS will clean things up for you anyway.
I was mistaken. Perhaps we can add a load function without errors to avoid this situation.
There's a loadNoFail i think
There's a loadNoFail i think
If use loadNoFil, how do we check a function valid?
if (vki.dispatch.vkGetPhysicalDeviceProperties2KHR != undefined) is useless.
Sometimes, the diver is strange, a extension is valid, but related function is invalid, so I must check the function is valid manually.
With the non-failing load(), there can still be a resource leak in the example because allocating the memory for the wrapper can still fail and then the instance or device is not destroyed.
This could simply be solved by moving the allocation up, but I still think the destroy functions would make more sense on the same level as the create functions. They also appear next to each other in the vk.xml.