TBF I have to thank CircleCI for sending me no less than three warning
e-mails about Xcode image deprecation. I just didn't bother
updating until it started actually failing.
I kinda get the point, to avoid rogue third parties tainting my
ŕepositories with nasty backdoors, yes, but unless *everything* on the
way to the server including DNS queries is encrypted, then it's still
just a half of the solution and any silly corporate firewall can still
prevent me from cloning stuff from github dot com.
There's a lot of places in the code that assume macOS is never GLES, and
with the increasingly rotten native GL support on Apple platforms people
are switching to ANGLE. So we should make sure this use case works.
Took me a while (several years?) to figure out a way to benchmark this
without basically duplicating the testing effort and without new
variants being too hard to add.
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.
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?!).