I was slowly getting cancer from having to write the unreadably awful
VK_FORMAT_R666G666B666A666_SRGB all the time. Besides that:
- All pixel formats are documented to show what's guaranteed for them
by the spec. Pretty useful I'd say.
- The old hasVkFormat() and vkFormat() converters operating on a
VkFormat are deprecated in favor of new hasPixelFormat() and
pixelFormat() that use the PixelFormat enum. Similarly as done in the
GL wrapper.
- All APIs that took a VkFormat before take a PixelFormat now, together
with having conveinience overloads for Magnum::PixelFormat and
Magnum::CompressedPixelFormat. Again similarly as done in the GL
wrapper, also the first step on being able to *directly* use data
imported with the Trade library with Vulkan.
There was a nasty issue when moving the Device -- because the Queue
instances are populated with the Device pointer in the constructor,
moving the Device makes the Queue device pointer invalid and those
instances are useless. Discovered this when using VulkanTester to test
an upcoming Queue::submit() -- until then, the Device pointer in the
Queue wasn't really used for anything and so this wasn't known.
Making the Device immovable is thus the only sane way to keep the
current Queue retrieval workflow, which I'd say is much cleaner than
having to manually query the device for queues later using some
error-prone indices and whatnot. On the other hand, this finally makes
it possible to have a failable device creation, instead of the device
creation failing on an assert (or failing silently when
CORRADE_NO_ASSERT is defined). This is consistent with how the GL
wrapper works.
Also, because all device-dependent objects need to keep a pointer to the
originating Device in order to access Vulkan function pointers, having
it immovable makes it considerably faster. I'll make Instance immovable
with tryCreate() next because it seems like a good thing to do there as
well.
I was hesitating a bit with the <chrono> include but I can't think of
anything better right now. It's "only" 4k lines on C++11 (and I bet most
of it is <type_traits>), so should be fine.
This was way more pain that initially expected, especially in regards to
preserving externally-specified pNext chains without writing to them in
any way.
This is what I needed BigEnumSet for -- good thing I didn't even try to
have 128-bit enums because I'm now at 110 values and it's still far from
complete. Next step is enabling those features when creating a device,
which should hopefully be a lot less code, reusing most of what was
here.
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).
It was printing 0 before, which isn't correct. Also why not print both
values? Printing just the first one would hide issues where the second
is accidentally 0 or some other wrong value.
I was about to make a NoInit / "from Vulkan" constructor that allocated
but then fortunately stepped back in horror and realized what a mess
that would be. Expanded the overview / guidelines to make sure this is
guaranteed.
Vladimír Vondruš