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.
Well, no wonder it OOMs with 38 parallel jobs on ~10-20 GB RAM depending
on how the VMs are loaded, heh. Will revisit when I get rid of more STL,
this has to suffice for now.
Otherwise I'd need to duplicate that for clang-cl, mingw and so on. It's
enabled only on MSVC 2019 and newer, because I don'r really care about
older versions -- those are mainly for compatibility with existing code,
and Vulkan is not existing code yet.
It's not using Android's native Vulkan library because that's only since
Android 24 and emulator for that version doesn't even start. So we use
our own minimal driver instead.
On Ubuntu, because SwiftShader Vulkan doesn't compile on GCC 4 (or 5)
anymore, we use 4.8 on 16.04 for compile-test against libvulkan-dev and
18.04 for render-test with SwiftShader.
On Mac, because we want to work with both MoltenVK and Vulkan Loader, we
compile-test against MoltenVk in the generic "all build" and render-test
against SwiftShader on a new, Vulkan-specific build. That requires us to
supply our own loader as well -- apparently no such thing is on
Homebrew, which is kinda silly (doesn't anybody do real Vulkan work on
this crazy platform?!).
This makes it possible to:
- finally use Magnum as a CMake subproject on Windows and have your
executables not fail to run with a "DLL missing" error (and the
setting is put to cache so superprojects just implicitly make use of
that)
- run tests on Windows without having to install first
- use dynamic plugins from a CMake subproject on any platform without
having to install first or load them by filename --- and the plugin
directory is now easily discovered as relative to
libraryLocation() of the library implementing given plugin interface
Three new builds (GL, GLES2, GLES3), Vulkan is now built with just MSVC
2019; removed 2015 RT builds because nobody cares and axed also GLES
2015 builds. In total it's one build less (well, the RT ones are
really slow, so way more than that in fact). Yay!