This commit adds support for compiling Dolphin for ARM on MacOS so that it can
run natively on the M1 processors without running through Rosseta2 emulation
providing a 30-50% performance speedup and less hitches from Rosseta2.
It consists of several key changes:
- Adding support for W^X allocation(MAP_JIT) for the ARM JIT
- Adding the machine context and config info to identify the M1 processor
- Additions to the build system and docs to support building universal binaries
- Adding code signing entitlements to access the MAP_JIT functionality
- Updating the MoltenVK libvulkan.dylib to a newer version with M1 support
Because we have an old-style find script that does not define a proper
CMake target for libusb, we need to use ${LIBUSB_LIBRARIES}
rather than "usb".
Ideally, we would fix the find script to define a target. However,
this issue breaks the fifoci-ogl-lin-mesa builder and I'd prefer it
to be fixed sooner rather than later.
On clang-11 build failed as:
```
[ 42%] Building CXX object Source/Core/Core/CMakeFiles/core.dir/PowerPC/Jit64/Jit.cpp.o
In file included from ../../../../Source/Core/Core/PowerPC/Jit64/Jit.cpp:5:
In file included from ../../../../Source/Core/Core/PowerPC/Jit64/Jit.h:21:
../../../../Externals/rangeset/include/rangeset/rangesizeset.h:325:3: error: unknown type name 'size_t'; did you mean 'std::size_t'?
size_t size() const {
^
```
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
/Externals/liblzma/config.h #defines HAVE_PTHREAD_CONDATTR_SETCLOCK
which results in /Externals/liblzma/tuklib/mythread.h calling the
function pthread_condattr_setclock. This function doesn't exist in
macOS 10.12+, which are the only macOS versions Dolphin supports, but
inserting an include guard makes macOS use an alternate function.
On Linux, if shared zlib is present, zlib.h is always available and -lz
links to zlib, even if you don't run find_package(ZLIB).
For some reason I have zlib installed on Windows (possibly from vcpkg),
so find_package(ZLIB) succeeds and ZLIB_FOUND is true.
When Dolphin uses shared zlib on Windows, the problem is that zlib.h
is not in the default include path, and the CMake target is called
ZLIB::ZLIB and there's neither a target nor a library called z.
However, both find_package(ZLIB) and add_subdirectory(Externals/zlib)
create a target called ZLIB::ZLIB, so I'll switch to that instead.
Hopefully this change doesn't break anyone's build.
This updates glslang to commit 4fc7a33910fb8e40b970d160e1b38ab3f67fe0f3
which is the current version listed in the known_good.json file for the
version 1.2.131.2 of the Vulkan-ValidationLayers repo.
Allows us to migrate off of printf specifiers and have more type-safe
formatting facilities. It also allows for custom type support as well.
fmt is also on track to have part of it standardized within C++2a, so
this will also lessen the transitional work necessary later on by
allowing new code to use it.
This simply adds the library but doesn't do anything with it yet.
On a few of our buildbot instances, we get warnings about the usage of
deprecated functions. We should correct these, especially if we're
delegating to system versions of the libraries if they're available.
However, in order to do that, we need to update our library variant from
2.1.1 so that the non-deprecated alternatives are actually available.
The CMakeLists file for the static zlib checks for presence of
unistd.h, but it doesn't properly define HAVE_UNISTD_H if it's found.
This change adds the necessary preprocessor definition if unistd.h is
found.
Upstream zlib handles this with by configuring zconf.h with CMake:
cacf7f1d4e/zconf.h.cmakein (L11)
Dolphin's static version of zlib doesn't do this, which is why setting
Z_HAVE_UNISTD_H in zlib's CMakeLists.txt isn't enough.
This probably wasn't noticed since because most *nix systems will use
the shared zlib. Force use of the static zlib (comment out
find_package(ZLIB) in the root CMakeLists.txt) and you'll see implicit
function declaration warnings during its compilation.
In some cases, this is required to avoid eventually getting a
USBD_STATUS_BAD_START_FRAME error back from the Windows USB stack.
This makes the libusbK code match the behaviour of the Linux backend.
It appears that the libusbK backend tried to get this behaviour by
setting StartFrame to 0. However, libusbK docs state that:
"Specifing 0 for KISO_CONTEXT::StartFrame (start transfer ASAP) is
restricted to the first transaction on a newly opened or reset pipe."
Shawn Hoffman