VulkanMemoryAllocator-Hpp
VulkanMemoryAllocator-Hpp copied to clipboard
YaaZ
Missing Support for Vulkan RAII Headers
Alongside Vulkan-Hpp, the library has included support for RAII types, and is one of the cleanest ways of writing Vulkan code. As VulkanMemoryAllocator follows Vulkan's design philosophy so closely, and as VulkanMemoryAllocator-Hpp also mirrors Vulkan-Hpp, I think it would be beneficial to add support for RAII types in this project as well.
To address the obvious question of "why not just use UniqueHandle", I'd use the same reasoning behind why many prefer vk::raii to UniqueHandle. The RAII handle wrappers do more than simply properly destroy the object when it goes out of scope -- it also ensures that no invalid handle can exist. It is perfectly valid (just as with std::unique_ptr) to default construct a UniqueHandle, resulting in an invalid object that must be queried for validity before it can be used. The RAII wrappers generally result in much more expressive code and lower potential for bugs to be introduced:
vk::raii::Device device(physicalDevice, vk::DeviceCreateInfo(...));
Or for VMA RAII:
vma::raii::Allocator allocator(vma::AllocatorCreateInfo(...));
vk::raii::Device has no default constructor, and all constructors throw on error, meaning no invalid vk::raii::Device can be created. RAII handles also define a move constructor and delete the copy constructor to ensure each handle is unique.
Additionally, the RAII handles provide helper methods to move functions into handles they are most closely related to. Instead of:
device.bindBufferMemory(buffer, memory, memoryOffset);
void* pBuffer = allocator.mapMemory(allocation);
We have the following:
buffer.bindMemory(*memory, memoryOffset);
void* pBuffer = allocation.mapMemory();
The syntax is cleaner, and more importantly, the semantics are expressed clearly. The number of arguments per function call is reduced, and functionality is moved into the most strongly related handle class. Documentation is easier to browse and understand, and the code is generally more readable. The generator rules would likely need to be modified to support the new syntax, and vma::raii::Allocator would need to take a vk::raii::Context in its constructor, but it would certainly add consistency across the Vulkan ecosystem for anyone using the RAII library. <vulkan_raii.hpp> is a valuable library that I believe would make a great addition to VulkanMemoryAllocator-Hpp.
For reference, here is the Vulkan RAII Programming Guide, it includes a good description of all the benefits using the RAII headers can provide.
Agree, that would be very nice to have. And there's also one cool thing about RAII you didn't mention - each object keeps its dispatcher instead of it being a template argument, so there's no template boilerplate or implicit global state (VULKAN_HPP_DEFAULT_DISPATCHER) as with UniqueHandle.
The problem with generating RAII is that there are much more exceptions than with unique handles, so it will end up like 50% generated and 50% handwritten. I hope some time I'll find a time to implement this if nobody does this first :)
And regarding passing vk::raii::Context to vma::raii::Allocator constructor, there's already an utility function which can extract vma::VulkanFunctions from RAII dispatcher: https://github.com/YaaZ/VulkanMemoryAllocator-Hpp/issues/11.
I'm happy to get started on it, but I thought I'd make sure there wasn't any work already done first. I've been poking through the generator code and it doesn't seem too bad. I'll open a branch in my fork and put a link here once I've got something to show
I'm also looking for this feature to be implemented. But meanwhile, is there a way to make vma-hpp interact with vulkan-hpp raii? Or we Just can't use them at All?
