I named it RasterizationPipelineCreateInfo and not
GraphicsPipelineCreateInfo because there's now a
RayTracingPipelineCreateInfo as well, which is *also* graphics, and it
would be confusing for everyone except people already drowned in Vulkan
naming quirks.
Name the move constructor/assignment arguments so it's clearer that it's
indeed a custom implementation and not just a defaulted function moved
into the cpp.
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.