Metal replay serialization uses dummy wrapped metal objects ie.
case MetalChunk::MTLLibrary_newFunctionWithName:
return m_DummyReplayLibrary->Serialise_newFunctionWithName(ser, NULL, NULL);
case MetalChunk::MTLRenderCommandEncoder_setRenderPipelineState:
return m_DummyReplayRenderCommandEncoder->Serialise_setRenderPipelineState(ser, NULL);
case MetalChunk::MTLBlitCommandEncoder_endEncoding:
return m_DummyReplayBlitCommandEncoder->Serialise_endEncoding(ser);
Reuse the same constructor with NULL real metal object instead of making a new constructor
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.
baldurk