Because that's what it is, after all. Also mention this naming
difference in the Vulkan wrapping overview.
I was wondering if I should rename QueueFlag::Graphics too, but since
graphics queues are used for (not really rasterization-specific) image
copies as well, and ray tracing is actually done on compute queues, I
don't think renaming to Rasterization is a good idea. Clarified the
comments at least.
This was way more pain that initially expected, especially in regards to
preserving externally-specified pNext chains without writing to them in
any way.
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.
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.
Thus it has no place in the general overview docs of Vk::Instance and
Vk::Device. Better to put it into the VUlkan wrapping docs, where it
also makes sense to have both the device and instance side together.
Vladimír Vondruš