Originally I wanted to save people typing and provide "reasonable
defaults" for the image layout, however shortly after I realized I can't
express even the simplest case in the Vulkan Triangle example with
those.
Furthermore the case of having default load/store operations are so
rare that it isn't worth an extra API which tricks the user into
thinking the clear/discard operations are meant to be done somewhere
else. I realized this because it was actually harder to explain these in
a second step than introducing them right from the beginning.
Finally, because there's so many different structures to fill, the
implicit constructors weren't a good idea either, as it again tricked
users to think just PixelFormat or just an index is the parameter, with
nothing else, and then left them wondering where all the other important
params go. Same with {} used instead AttachmentLoadOperation::Load /
AttachmentStoreOperation::Store, unnecessary confusion there so don't
even suggest that.
After I implemented the render pass wrapper, seeing how the
RenderPassCreateInfo structure and its dependencies were HUGE compared
to the actual tiny and lean RenderPass, I felt uneasy dragging their
definition along to every place where a RenderPass gets used. It's not
as bad with the others, but as new extensions are implemented I expect
that to get the same.
This change makes it easier for me to accept that Image.h / Buffer.h
depends on Memory.h. There isn't a real measurable difference when
building Magnum itself (50 ms out of 7 seconds for the Vk library
alone), but that's because most of the code (and tests) needs the
CreateInfo structures anyway.
Although the APIs don't look like that right now, in many cases creation
of a particular Vulkan object isn't all that's there for it. So change
the section names from a generic "Usage" to "Creation".
Quite a big chunk of work, further expanded due to how
VK_KHR_create_renderpass2 is designed -- basically, due to the
tightly-packed nested structures that got replaced with their "version
2", we can no longer just extract the previous structure for backwards
compatibility, but instead have to deep-copy everything to a newly
allocated memory.
Thanks to the the new ArrayTuple structure and a few design iterations I
managed to kick the backwards-compatiblity code into just a single
allocation, while still keeping it possible for the "version 2" code
path to be fully allocation-free (if one passes a completely filled
VkRenderPassCreateInfo2 structure there).
Vladimír Vondruš