Next up is *the unthinkable*, a Vk::Mesh. After that I'll finally have
enough APIs exposed to document everything including command buffer
recording and submission.
Similar to PixelFormat, to filter out values that make no sense as a
vertex format (such as sRGB) and add others (such as doubles). And
documenting which are guaranteed to be supported and which not. The
hasVkFormat(Magnum::VertexFormat) and vkFormat(Magnum::VertexFormat)
were also deprecated in favor of the new hasVertexFormat() /
vertexFormat() APIs.
These were implemented long before ArrayTuple was a thing and while the
allocation saving optimization makes sense, the implementation is way
too error prone.
This also means Array (and thus <new> and other heavy shit) isn't
included in the headers, which leads to further slimming of compile
times across the library.
Since depth/stencil images can't be linear, I needed buffer/image copies
to test those, and conversely to test buffer/image copies I needed image
clears.
A pretty big chunk of work, and it led to a discovery of a SwiftShader
bug, which I will work around next. First Vulkan driver workaround, so
the whole scaffolding needs to get added as well.
Because (after I read a bunch of articles on this) it can actually be
understood easier that way -- the now-documented snippet shows that in
practice. Also expanded the constructor and usage docs a bit.
Yes, I had to make the enum mapping table in the previous commit because
I didn't remember anymore if I exposed this already or not. The API
surface is *huge*.
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.
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.
Vladimír Vondruš