Breaking this macro yet again, sorry -- now the result values are
specified last and there can be any number of them, however they need to
be all prefixed, as adding the prefix implicitly with the macro would be
too much of a pain to implement, especially given the poor preprocessor
capabilities of MSVC.
This was way more pain that initially expected, especially in regards to
preserving externally-specified pNext chains without writing to them in
any way.
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.
Today I spent six hours wrongly convincing myself that it's a driver bug
when vkGetPhysicalDeviceProperties2() is null on a 1.1 instance for a
1.0 physical device. It's not a bug, it's me not reading specs
carefully.
This commit thus basically moves all Instance-level extension-dependent
state to DeviceProperties, because it's actually device-dependent. Which
makes the DeviceProperties class quite heavy and thus it's good it was
readied to be transferred all the way to a Device instance a few commits
back -- I don't really want to do all the dispatch, string processing,
sorting and other mess more times than strictly necessary.
In addition, DeviceProperties::apiVersion() got renamed to version() and
a new isVersionSupported() API got added, mirroring what's on Device
itself; plus thanks to the chicken-and-egg problem of having to call
vkGetPhysicalDeviceProperties() twice, the device version and other
things can now be retrieved in a slightly more efficient way.
This avoids allocating a potentially large array in case just the first
device is needed. Originally I did this in a hope to avoid a stall + CPU
power management issues due to some bad shit in the AMD driver, but it
seems that enumerating even just one device still makes it stall. Sigh.
Similarly to Corrade Assert.h, so it's possible to include this header
without having to worry about irrelevant overhead when asserts are
disabled.
Also test it properly, as it should have been from the start.
I'm a bit unsure why there's a device extension that actually gets used
on an instance and doesn't need any enabling (and thus there's
currently no way to disable it to test all code paths, hmm).
Memory type flags are put into a new, separate Memory.h header as those
will be needed more often than the (ever-growing) DeviceProperties --
from Image and Buffer constructors, in particular.
Vladimír Vondruš