They're not parsed since 6b22a11170
(2020), so there's no point in keeping those workarounds. They're only
kept in utility application sources as they're parsed for pages, and in
tweakable implementations where it's easier to just copypaste the whole
ifdef expression from the header every time instead of modifying it to
not include DOXYGEN_GENERATING_OUTPUT.
Compared to Corrade, the improvement in compile time is about a minute
cumulative across all cores, or about 8 seconds on an 8-core system (~2
minutes before, ~1:52 after). Not bad at all. And this is with a
deprecated build, the non-deprecated build is 1:48 -> 1:41.
Heh, somehow every time I run the full battery of tests I discover
another failure.
NVidia, with Vulkan version forced to 1.0 and when VK_KHR_maintenance1
isn't enabled, returns VK_ERROR_OUT_OF_DEVICE_MEMORY. So whitelist that
error as well and treat it as allocation failure and not a fatal error.
Not sure what I did in 3e4e1bde69 but that
updated XFAIL is now an XPASS on NVidia. Because, apparently, the clear
clears the whole memory, not just the image area, so even though the row
pitch is different, the comparison of the initial N bytes passes.
So I'm ditching the silly XFAILs and doing a proper image comparison that
includes the actual driver-dependent row pitch for the images. Finally,
the image-to-image copy was flat out wrong because it didn't take the
*input* row pitch into account, so it copied garbage and then compared to
a different kind of garbage.
The check for memory size was enough for llvmpipe, but not for
SwiftShader. And now it wasn't enough for NVidia either, so let's just do
it properly.
Ideally of course this would compare always. Don't feel like doing that
right now tho, so it's just a TODO.
Similar to previous commit, Doxygen 1.12 being finally strict and
refusing to link to this. There's a new (inline) namespace in between,
and it needs the Corrade:: prefix also.
Doxygen 1.12 has no longer a completely insane matcher and discards
those as it should. With 1.8.17 classes had to be referenced with
Corrade:: but functions, typedefs and variables didn't need to be and it
was a complete utter chaos.
It was an XFAIL in some other case already, do it here as well -- it
seems that llvmpipe now never fails the allocation. Not sure since when
that happens, because several Mesa versions until 23.3 (?) had a
regression with skinning shaders, leading to the automated tests failing
even before they could reach the llvmpipe variant of Vk tests.
An ad-hoc solution was already done in DebugTools::screenshot(), now I
need it in another place. While not as fast as the O(1) mapping from
the generic format to the API-specific ones due to the potentially
linear lookup, it definitely could be useful in general.
Not that C++ STL and exceptions would be anything to take inspiration
from, but there's std::out_of_range. Python IndexError is also specified
as "index out of range", not "bounds".
Partially needed to avoid build breakages because Corrade itself
switched as well, partially because a cleanup is always good. Done
except for (STL-heavy) code that's deprecated or SceneGraph-related APIs
that are still quite full of STL as well.
Among other things this makes it possible to use Utility::copy() instead
of a manual loop and grow arrays with std::realloc() instead of always
new'ing-copy-deleting because Containers::Pair is trivially copyable.
It was creating the pool with 7 buffers, which the driver could as well
just round up to 8 and then allocating 8 would not fail. The test used
to work on Mesa before but not anymore. So I'm creating the pool with 8
and askin for 80 which should definitely fail.
There's a lot more failures on NVidia, I "fixed" those by deleting the
NVidia Vulkan ICD file for now.
Triggers the new OOB assertion in ArrayView element access APIs.
"Technically" this was okay, since converting a BufferMemoryBarrier to
VkBufferMemoryBarrier is just `return this;` (and a cast), which if
`this == nullptr` returns `nullptr`. But practically this probably
triggered all sorts of UB. Haha.
This significantly simplifies everything -- because a single type can
now handle both StringView lists and char* lists, we no longer need a
templated private helper to avoid allocating a temporary array of
unified type. Instead, the whole extension initialization can be done
directly in the initialize() helper, by simply iterating over the
argument.
Yay, this is probably the nicest improvement caused by StringIterable so
far.
It's four pointers, twice as much as what would be acceptable. Not sure
why this happened, maybe because all those cases used an ArrayView
before and so I just changed the type without considering the difference
in its size?
Unfortunately this change also means a bump in the plugin interface
string, thus all scene converter plugins have to be updated as well.
Same as the previous commit in MeshTools -- allows to pass a
Containers::Array<DescriptorSetLayoutBinding> to it without having to
form a list of references first.
I wondered if I should put them into the GL/VK startup log, but
while definitely useful, they don't really have any relation to GPU
drivers. So it's just here for now.
Vladimír Vondruš