The 5000-line monster took 3.3 second and over 320 MB to compile. While
that may be fine for other projects, that's completely unacceptable here
-- and it seems that this one test is the cause for most of the recent
OOM issues on the CI.
Moreover, I'll be expanding MaterialData with thinfilm, sheen and other
properties that got recently added to glTF and expanding a single test
file with those simply wouldn't scale anymore.
Because the drivers don't seem to check that features are actually
supported for anything beyond VkPhysicalDeviceFeatures2, we have to do
that instead. Additionally, we also check if a feature is enabled but
the extension that needs it is not (which isn't checked by drivers
either).
This was way more pain that initially expected, especially in regards to
preserving externally-specified pNext chains without writing to them in
any way.
It's reusing an internal file to make them display nicely, I hope that
doesn't make it too ugly / too sad that library users can't do the same
thing in their code.
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.
Not exactly sure about the semantics yet, so keeping it private. In
particular, if this should be the default behavior for
isExtensionEnabled() (would make sense probably?), or for
isExtensionSupported(), and what should be the API that separates the
version from the extension so we can decide which function pointer to
fetch.
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.
Sigh, again. That's what I get for removing std::string only from some
APIs and not all. Explicitly fetching the argument values as a
StringView everywhere now, it avoids a copy so it's good to do even if
not strictly needed.
Vladimír Vondruš