Actually sdk-1.2.154.1 for Vulkan-Loader.
glslang is updated to bacaef3237c515e40d1a24722be48c0a0b30f75f which is the
known-good version for Vulkan-ValidationLayers 1.2.154.0.
COPYRIGHT.txt was synced with the current version of the glslang LICENSE.txt,
and `glslang/register_types.cpp` now uses the upstream definition for its
default builtin resource instead of hardcoding it.
This code currently isn't compiled (and cannot compile).
We plan to re-add OpenGL ES-based renderer(s) in Godot 4.0 alongside Vulkan
(probably ES 3.0, possibly also a low-end ES 2.0), but the code will be quite
different so it's not relevant to keep this old Godot 3.2 code.
The `drivers/gles2` code from the `3.2` branch can be used as a reference for
a potential new implementation.
Implements exit codes into the engine so tests can return their statuses.
Ideally we don't do this, and we use FIXUP logic to 'begin' and 'end' the engine execution for tests specifically.
Since realistically we're initialising the engine here we don't want to do that, since String should not require an engine startup to test a single header.
This lowers the complexity of running the unit tests and even for
physics should be possible to implement such a fix.
Upgrade OIDN to 1.1.0, the latest stable version that doesn't need
the ISPC compiler.
Documented the changes made during the removal of TBB and added a patch
file for them.
Upstream development restarted after 13 years. Changes:
2020-02-02: Version 0.5.0
Minor speed improvement on the decompressor.
Prevent memory violation when decompressing corrupted input.
2020-01-10: Version 0.4.0
Only code & infrastructure clean-up, no new functionality.
The comment mentioned a conflict with libwebsockets, but we actually
still get this conflict even now that we don't use libwebsockets.
Not sure what component is clashing but we should basically just keep
this patch.
Follow-up to #36823.
Upstream removed the option in KhronosGroup/Vulkan-Loader#260, which
breaks our current use case.
This commit reverts KhronosGroup/Vulkan-Loader#260 is our vendored
loader.
We may need to re-evaluate how we link the loader, but until then,
reverting this PR fixes Windows support after the upgrade to a recent
SDK version in #36932.
