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.
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.
Similar to the change done in Corrade, see the commit for details:
878624ac36
Wow, this is probably the most backwards-compatibility code I've ever
written. Can't wait until I can drop all that.
While branching on a compiler is rather common, checking a particular
compiler version should be needed only rarely. Thus minimize use of such
macros to make them easier to grep for.
It limits the support for CMake 3.12+, but it's much less verbose and I
don't expect people to use ancient CMake versions with IDEs like Xcode
or VS anyway, so this should be fine.
This test is run only on Android because natively CMake treats SIGABRT
as a failure always, even if I want to just check the output. So it
got outdated. Sigh.
The type is now extended to 32 bits. In the GL and Vk libraries it means
one can now do things like
MeshIndexType type = meshIndexTypeWrap(GL_UNSIGNED_BYTE);
and passing that to GL::Mesh or Vk::Mesh will cause it to use the value
directly, instead of doing a mapping from a generic type. The *real* use
case for this is however to allow custom index buffer representations in
Trade::MeshData. Support for that will be hooked up in the following
commit.
The validation layer complained. So enable these two implicitly as well
if we're on 1.0.
And since those are now disabled in certain test runs to test related
code paths, DeviceVkTest needs to be updated to skip affected tests if
this happens.
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.
Together with DescriptorBindingFlags, because it affects the design in a
rather specific way and it wouldn't make sense to postpone this and
forget all again until it becomes needed.
Together with SamplerFilter, SamplerMipmap and SamplerWrapping enums
convertible from the generic versions, which finally deprecate the
last remaining vk*() conversion functions in Enums.h and thus the whole
header as well. The EnumsTest executable is also no more, as the rest of
it now resides inside SamplerTest.
Its only use was for specifying N-dimensional SamplerWrapping because,
compared to a Math::Vector, it had an implicit constructor from a single
value (whereas the Vector has it explicit). I solved that by simply
adding a few single-value overloads where it mattered. There, done. No
need for this weird thing and confusion with Containers::Array anymore.
All places that used it now use Math::VectorN<SamplerWrapping>, but the
class is still included for backwards compatibility purposes, together
with providing implicit conversion from and to a Vector.
Together with:
* CommandBuffer::draw()
* Support for indexed and non-indexed meshes
* Support for setting primitive and stride dynamically
I took one shortcut and vkCmdBindVertexBuffers() is currently called
once for each binding. The interface is ready for this, but I'm not yet
100% sure how to test that it actually does batch the buffers, so it's
left at the lazy implementation for now.
So it's possible to do
Vk::Mesh mesh{Vk::MeshLayout{}
.addBinding(...)
.addAttribute(...)
};
Without this, the above will result in a dangling layout reference.
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.
Vladimír Vondruš