* There's not a good accepted terminology for this kind of event, and for
historical reasons 'drawcall' has been the accepted term, even though
that can be quite confusing when a dispatch or a copy is a 'drawcall'.
* This is particularly highlighted by the event browser filters where
$draw() includes draws and dispatches, but $dispatch() only includes
dispatches, it's hard to intuitively understand why $draw() matches all
of these calls.
* As a result we've defined the term 'action' to cover these types of
events in the same way that we defined 'event' in the first place to
mean a single atomic API call.
This commit adds x86/x86_64 support for RenderdocCmd APKs for Android.
This is needed mostly to support Chromebook devices. Many of them are
based on x86_64 CPUs.
* cmake's built in platforms/Android.cmake for some reason sets
CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH to OFF which prevents any subsequent
find_program or find_package from locating any executables in the system PATH.
This can break finding java among other things.
* This prevents unnecessary conversions back and forth between rdcstr and const
char * when going through interfaces. In the OS specific layer this is rarely
an issue because most of the implementations don't convert to rdcstr, but it
is convenient to be able to pass in an rdcstr directly. The few cases where
there's an unecessary construction of an rdcstr is acceptable.
* A couple of places in the public API need to return a string from a global
function, so can't return an rdcstr due to C ABI, so they still return a const
char *.
* Similarly const char * is kept for logging, to avoid a dependency on rdcstr
and because that's one place where unnecessary conversions/constructions may
be impactful.
Updated permissions for the renderdoccmd app based on which version of
android the app is running on
**WRITE_EXTERNAL_STORAGE for <R
**MANAGE_EXTERNAL_STORAGE for >=R
Updated the Java portion of renderdoccmd to check/request the correct
permission based on android version
Changed the file path for renderdoc files on Android based on the
version of Android the connected device is running
**/sdcard/Android/data/$PACKAGE_NAME for <R
**/sdcard/Android/media/$PACKAGE_NAME for >=R
* We instead always have 3rdparty/ in the relevant include search paths and rely
on that. Each library still has its own unique base dir within 3rdparty to
clarify where the include is coming from.
* It's required for replay applications to call InitialiseReplay() before doing
any work, and to call ShutdownReplay() once they're finished.
* This lets us do more heavyweight shutdown work before global destructors are
being invoked and the RenderDoc instance is being destroyed.
* Anything that needs to be shut down during capture still has to happen in
RenderDoc::~RenderDoc since we obviously can't get the application to call a
shutdown function in that situation.
* This is needed so that the functional tests can elevate and run renderdoccmd
to register the vulkan layer, if needed.
* At the same time remove the old spammy message and ignore flag - this dates
back to before the UI existed, and that should be the way users run RenderDoc
generally and it has a good UI for walking through layer registration if
needed.
* The command is always available, but will only show up in help if attention is
needed.
* Also fix registering installs on shared drives.
Converting std::wstring to std::string by constructing the latter with
wchar_t iterators result in implicit conversion of wchar_t to char which
trips Visual Studio 2019 compiler into throwing a warning of potential
data loss during conversion. Use conv() helper function to do the
conversion and please the compiler at the same time.
* Subresource handling is more consistent - we pass around a struct now that
contains the array slice, mip level, and sample. We remove the concept of
'MSAA textures count samples as extra slices within the real slices' and
internalise that completely. This also means we have a consistent set
everywhere that we need to refer to a subresource.
* Functions that used to be in the ReplayOutput and use a couple of implicit
parameters from the texture viewer configuration are now in the
ReplayController and take them explicitly. This includes GetMinMax,
GetHistogram, and PickPixel.
* Since these functions aren't ReplayOutput relative, if you want to decode the
custom shader texture or the overlay texture you need to pass that ID
directly.
* This is only lightly tested and may break heavily. It is disabled by default
and must be explicitly enabled.
* In particular this is only known to work for Wayland use at capture time.
Wayland on replay is still unsupported. Known issues include: EGL pbuffer
surfaces are not implemented on Wayland, Wayland cannot get window dimensions,
and there are hangs/failures with GL and vulkan presentation with Wayland.
Remi Palandri