* We add a capture option that defines a soft limit we aim to keep under for
memory overhead during capture, excess initial states after that will be
stored temporarily on disk.
3rdParty source files and some renderdoc files which include 3rdparty header files
Disable "-Wshadow" for the whole of qrenderdoc render_python.cxx triggers the warning
Captures can be manually triggered from renderdoccmd capture <application> using F12 or from the UI on the in-development Metal replay branch.
The captures can be loaded and replayed on the in-development Metal replay branch.
The command buffer tracking and serialization are done by GPU submission order which is not necessarily the same as CPU commit order. The command buffer tracking for GPU submission order is currently using an rdcarray, this might change in the future to use a linked list if the performance of appending and deleting from the rdcarray becomes a performance bottleneck.
Does not include support for the presented MTLDrawable ie.
* Thumbnail generation of the final presented image.
* Serializing the presented texture ID.
Does not include support for initial state data.
No MTLBuffer data contents are serialized.
There is a lot missing and a lot of TODOs.
This is the basic structure for capturing which is then built upon.
Includes:
* register the Metal device as a frame capturer ie. AddDeviceFrameCapturer
* logic for triggering captures at Present ie. AddActiveDriver, StartFrameCapture, EndFrameCapture.
* Stopped declaring MetalResourceManager as a friend of WrappedMTLDevice which meant making the initial state-related APIs public instead of private.
* IFrameCapturer interface APIs
* Command buffer tracking for including in the output capture CaptureCmdBufCommit and CaptureCmdBufEnqueue.
* Serialise_MTLCreateSystemDefaultDevice(SerialiserType &ser)
* A helper class MetalCapturer which is derived from IFrameCapturer and registered with the RenderDoc instance. This is because Wrapped Metal classes can't have virtual tables as a requirement for how the C++ and Objective C overlay is implemented.
* The frame capture chunk and API AddFrameCaptureRecordChunk
* MetalInitParams data and serialization.
Helper Methods and Members in MTLDevice
* WaitForGPU()
* MTL::CommandQueue *m_mtlCommandQueue which is used to implement WaitForGPU()
* CaptureClearSubmittedCmdBuffers() & CaptureCmdBufSubmit()
* RegisterMetalLayer() & UnregisterMetalLayer() used to track active Metal swapchains
Details on the memory lifetime for WrappedMTLCommandBuffer
retain the real resource in WrappedMTLCommandBuffer::commit()
release the real resource when no longer needed to be tracked: for background capture in during WrappedMTLDevice::CaptureCmdBufSubmit, for active capture in WrappedMTLDevice::EndFrameCapture.
During capture (Background or Active)
* AddRef() record when command buffer is enqueued (explicit or implicit)
* Delete() record at end of command buffer submit
During Active capture
* AddRef() record in command buffer submit
* Delete() submitted command buffers as part of finalizing the capture
Added TrackedCAMetalLayer & ObjCTrackedCAMetalLayer to track the lifetime of CA::MetalLayer.
The CA::MetalLayer is tracked in the hook for CAMetalLayer::nextDrawable(), with ObjCTrackedCAMetalLayer set as an association to the CAMetalLayer. Then ObjCTrackedCAMetalLayer::dealloc() triggers ending the tracking.
* Most of the main entry points that can fail with relevant reasons now has a
way of specifying a message to return with it. This message can be displayed
to the user to give more information or context about an error.
* 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.
* 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.
Er2