macos-11 Apple Clang does not support -Wno-unused-but-set-variable
To fix CI
error: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-option]
* The D3D11 spec is unclear but checking sources including D3D11On12 it looks
like the defined behaviour for SO counters is to calculate the number of bytes
written and divide that by the VB stride on draw.
* Old captures can't be updated to work with this because the stride is unknown,
but new captures will work correctly as well as any data that is stream'd out
mid-capture.
socket APIs take an int for the socket file descriptor
send() and recv() return ssize_t not int
bind() takes "socklen_t" for the length of the sockaddr structure
3rdParty source files and some renderdoc files which include 3rdparty header files
Disable "-Wshorten-64-to-32" for the whole of qrenderdoc render_python.cxx triggers the warning
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
While Renderdoc already supported multiarch for where to install the
libraries with the LIB_SUFFIX option. The Vulkan layer was left out of
this loop.
Vulkan layers living in `/usr/share/vulkan/implicit_layer.d/` will use a
suffix before the `.json` to separate libraries of different
architectures. These layer files will then point to the architecture
specific `library_path` inside that json file.
Also updates the check in `LayerRegistrationPath` so it handles the
suffix as well. This way `renderdoccmd` won't complain about conflicting
json files.
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.
* This helps downstream forks to run CI without seeing a false negative in the
mac release build due to being unable to upload the final package to the
server.
* When selecting the first event in a command buffer the render state wouldn't
properly be updated. This is particularly bad if the state that changed is
being in/out of a renderpass.
* This was an extremely old bit of code from before vulkan 1.0 to detect a
common error. RenderDoc does not validate in general so delete this rather
than keep it up to date.
* We can't debug geometry shaders but we can scroll to them, as long as we have
the primitive. We can't differentiate instances currently without passing that
data through from the VS (and through tessellation, if it exists).
* This also disables the debug and goto buttons for printfs from shader stages
that don't support those operations.
* Previously this would be treated as std430 due to being 'tight' array packed,
even though std430 only allows as tight as the base alignment - which for a
float3 is 16-bytes still.
* AppInit_DLLs requires short paths to be specified, if they can't be created on
the volume we can't reliably enable the global hook.
* Detecting this programmatically is quite complex, but since we know the shim
file is always longer than 8.3, if we detect that the short path is the same
length as the long path we know short names weren't used.
baldurk