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.
Qt's QVulkanWindow has that and it seems useful, especially for weird
extensions like VK_KHR_memory_model where their structure layout changes
over time.
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.
Another thing I realized while writing docs, having to always put the
{}, {} things there is silly, and in many cases we need just one, not
all of them.
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.
I originally had this API there but then threw it away because it
encouraged inefficient use. However now it's really handy when writing
tests, so I guess I'll keep it.
Usually the validation layers should be expected to catch this, but in
this case we omit the pNext structure chain before it has a chance to be
caught by the layer, so the assert is needed.
I got a bit confused by the code, seeing it again after a few weeks, so
better explain the original intent to avoid getting confused again in
the future.
And remove the one case where storing the wrapper *really* isn't needed
right now.
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*.
A forgotten leftover from the initial RenderPass design. These used to
be created right at construction, but I eventually changed that to be
only done explicitly via a getter.