* If the RenderDoc UI connects to a program, opens then deletes the captures,
then closes and is opened again - we don't want to report those deleted
captures as if they still exist. This now clears out any captures that no
longer exist.
* We don't want to allow threaded evictions of resources while we're preparing
initial states, and we need to manage residency of heaps as well as individual
resources.
* For some of these it may be harmless, but it is apparently common for
applications to blindly use extenstion functions without checking that the
extension is available and this is the only way to make things robust and
prevent them from generating potentially broken captures.
CMake version 3.20 or higher (needed to support Xcode project generation)
clang version 12.0 or higher (needed to support arm64+x64 universal binary compilation)
XCode 12.2 is the oldest version which includes clang version 12.0
Changes to make metal-cpp options work nicely with RenderDoc serialization
_MTL_OPTIONS -> _NS_ENUM
RenderDoc serialization works with fixed sized types
Changes to make metal-cpp enums work nicely with RenderDoc serialization
NS::Integer -> std::int64_t
NS::UInteger -> std::uint64_t
RenderDoc serialization works with fixed sized types
Change hooking to use link time symbol address instead of runtime dlsym
Since OSX12 dlsym(RTLD_NEXT,...) returns the interposed symbol not the real symbol
* When a port is specified (with the usual :12345 suffix on the hostname) we use
that for remote replay connections. We disable target control enumeration
since that requires a port _range_ and captured applications self-assign those
ports. Those can still be accessed via a normal unsuffixed remote specifier -
even if there is no remote server running on the default port.
* Extensions will likely not be exported as real symbols, so we need to handle
the case of needing to fetch the onward pointer via eglGetProcAddress.
* We do this for non-extensions too, to try to fetch core functions that are
still NULL after hook initialisation. Since we do wholesale dlopen/dlsym
replacement on linux we cannot handle the case where an application checks for
function validity via just normal dlsym returning something, but then the
function doesn't exist in the real libEGL.so. We have no way of reporting that
the function actually doesn't exist because we have nowhere to call, and it
will crash. Trying to fetch the pointer via eglGPA is unlikely to succeed but
should do no harm as we don't set these function pointers anywhere else.
baldurk