* Unverified as yet, but the former is relatively straightforward and
not serialised, and the latter is quite similar to the NV dedicated
allocation extension.
* Drop support for now deprecated KHX sharing extensions:
- VK_KHX_external_memory
- VK_KHX_external_memory_capabilities
- VK_KHX_external_memory_win32
- VK_KHX_external_memory_fd
- VK_KHX_external_semaphore
- VK_KHX_external_semaphore_capabilities
- VK_KHX_external_semaphore_win32
- VK_KHX_external_semaphore_fd
- VK_KHX_win32_keyed_mutex
* And add support for the KHR promoted versions (which are almost the
same, with some minor changes).
After selecting an application to launch on Android, inspect it to see if
it contains the RenderDoc layer and required permissions. If it does not,
display a warning similar to desktop. When clicked, if only the layer was
missing, offer to patch the APK, uninstall, and reinstall, with the
warning that it doesn't work for all applications (or at all for GLES).
Also provides pointers to how to package the layer yourself.
The process works by using the host temp directory to pull the APK and
modify it. If the steps fail for any reason, the log is populated and
patching is halted.
This allows the library to be used as a Vulkan layer and shared
object for GLES debugging. It was already being renamed in the
distribution scripts. We've been renaming by hand for local
Vulkan development.
For commands that write to stdout multiple times before writing
stderr, the second ReadFile would hang indefinitely. This was
seen using "adb pull" with a sufficiently large APK (~20MB).
This code was inadvertently changing the working environment
of applications that called it. Hasn't been a problem until
we started calling scripts which need PATH to remain good.
* Every time clang-format applied to this file, it would add a new \
on the end of the first line of the comment. Splitting it into two
single-line C comments works around this behaviour.
* When statically linking libstdc++ by default the symbols are all
default visibility. This causes a problem if you statically link an
old libstdc++ then inject librenderdoc.so, and the application starts
using the old libstdc++ instead of the system's.
* Really we only want to use the static one for calls from
librenderdoc.so. In theory -Wl,--exclude-libs,libstdc++ should do this
for us, but it starts to cause bizarre crashes.
* Instead, we have to resort to a manual linker script which whitelists
which symbols should be visible. Normally we can do this just for our
own symbols with -fvisibility=hidden and __attribute__((visibility))
but that doesn't work for linked symbols apparently.
baldurk