* This is a consideration for any cases where binding numbers are relevant -
primarily D3D11 and GL - where the offset into an arbitrary (and possibly
fake) descriptor storage is not helpful but knowing the register binding
definitely is.
* If someone wants to look at the raw descriptor contents without respect to a
particular shader access they can use this query to determine a more useful
'name' for any given descriptor. On D3D11 and GL this gives the register
number, on Vulkan it gives the binding number (and array element). On D3D12 it
just repeats the offset effectively.
DebugShaderInputs struct contains existing the parameters:
sample
primitive
and a new parameter
view
Default constructor for DebugShaderInputs sets the parameters to NoPreference (~0U).
* On Android the end-to-end latency of a single call is large enough that doing
a call per-instance in a draw with a high number of instances is a real
problem
The implementation usage of m_BufferAddresses assumes the container is sorted and requires the use of lower_bound() API
Added rdcsortedflatmap subclass of rdcflatmap
Only expose upper_bound(), lower_bound() APIs in rdcsortedflatmap
The upper/lower bound APIs require a sorted container
Added logic to the entry point RENDERDOC_CreateRemoteServerConnection to shutdown the socket used to connect to a remote device when the function is used to test a connection (IRemoteServer **rend is null.) This previously created a handle leak, visible as accumulating /device/afd/ file handles on Windows.
Added logic to the Windows specialization of Process::LaunchProcess so it will close two handles: hChildStdError_Rd, and hChildStdOutput_Rd if the handles were created successfully but the process failed to launch. Previously these would accumulate during a remote probe for Android devices if ADB was not present or otherwise failed to launch.
* The enums are given after compute, to preserve indices for the normal vertex
pipeline.
* Mesh dispatches are considered a new action type, rather than being bundled
into the `Drawcall` type. This will allow them to be distinguished by API
backends as needed. The UI treats them as drawcalls
* We apply this universally even though it's not relevant to D3D11/GL. It means
a couple of empty array entries but it should not cause any significant
issues.
* Shader messages will be identified by group and thread as with compute
shaders. For mesh shaders there is an additional subdivision to identify them
by task group, since each task group can submit a grid of mesh groups.
* 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.
* Given socket corruption or network errors these strings could contain
unprintable characters so we sanitise them reasonably. This also ameliorates a
potential security concern with arbitrary strings being written to a log, but
these connections are still considered trusted and users should not be
exposing RenderDoc ports to the internet.
* This removes a potential narrow race where a capturer is removed or added on
one thread while another thread is iterating the list of capturers for target
control communication.
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.
* 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.
baldurk