Making room for MSVC 2022. GLES will be tested more than enough on 2019
and 2022. The RT port is rarely (if ever) used and obnoxiously slow, so
ES3 has to suffice.
Just the stuff that touches GL functionality in some way. Which
unfortunately means all of DebugTools and SceneGraph for debug
renderers, which then pull in also all of Primitives and all of
MeshTools.
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.