Repository: baldurk/renderdoc

Issue #439: Feature: Save partial log (range of events)
Created: 2016-12-06T07:44:55Z
I would like a new feature that allows me to extract part of the RenderDoc capture log (range of events from A to B) and save it as a new smaller capture log.
This would be highly valuable feature when sending bug reports to third parties (driver bugs to IHVs, engine bugs to Unreal/Unity/etc, RenderDoc bugs, etc). It would both help in avoiding sending confidential information (captures from unannounced game IP) to third parties and would make the capture significantly smaller (easier to send off-site). This feature would also allow easy construction of minimal case bug repro cases.
It would be important that the partial capture removes all references (names, initial data, etc) of resources that are not referenced in the selected range of events. Initial data of the remaining resources would need to match the state of the resources at the point of the first event in the selected range.

Duplicate issue #2940: [Feature] Capture trimming
Created: 2023-05-19T04:27:08Z
Description
"Trimming" means: given an RDC file, specify a range of Draw calls, and produce another RDC file that contains only those draw calls.
Trimming works by: having one RenderDoc instance capture another RenderDoc instance replaying the specified range of events.
The way it works is basically as follows:

Load two copies of Renderdoc's DLL:

Load renderdoc.dll and fetch its RENDERDOC_API_1_6_0 for capture
Load renderdoc1.dll and fetch its RENDERDOC_API_1_6_0 for replay
The reason is to be able to capture (meaning m_DeviceFrameCapturers gets populated), the DLL must be named renderdoc.dll



Environment
In terms of operating system, I have only tested Windows. I guess it should work similarly on other systems?
In terms of Renderdoc API: I need to expose the following functionalities into the in-app API:

SetReplayApp() so I can set one RenderDoc instance to replay mode and leave the other in capture mode
Get an ID3D11Device* (or other drivers) from a IReplayController for off-screen capture
ReplayLog(startEid, endEid, replayType) needs to be added to D3D11Replay, D3D12Replay, GLReplay, DummyDriver, ImageViewer, ReplayProxy

An example code change is here.
The example code change only adds D3D11, captures with other APIs might be able to get trimmed with the same approach.
Sample run:
C:\Temp>renderdoctrim.exe x.rdc 20 40
Will trim x.rdc and keep event range [20, 40].
Trimmed file written to x_trim_20_40_capture.rdc

Closing comment (2023-05-19T08:24:11Z): This is a duplicate of #439. In general it's a low priority request as it has a large implementation complexity and this self-capture approach is not the right way to do it vs. modifying the capture directly.
It's also typically true that a) RenderDoc captures are already relatively small being ~frame sized, so truncating them is not something needed regularly, and b) in the cases where you do need a smaller capture it is in the large majority of cases easier to use the in-application API to capture a smaller subsection of the application in the first place rather than shrinking a capture.
I'd also suggest that you explore the conversion of captures to/from structured data. Although doing it automatically is not currently possible, it still means that manually you can remove sections of the capture.
The implementation you describe is not feasible in general, but you can hack this locally on windows only (and I do, as it's useful for RenderDoc development) without needing any code changes by renaming the renderdoc project to rdocself and renderdoccmd to rdocselfcmd. If you run the UI through rdocselfcmd and you will get two new menu items to 'start capture' and 'end capture' that allow you to capture internal work, but you could modify the code to capture different sections if you wanted. Capturing an arbitrary subset of EIDs is not possible for vulkan or D3D12 that way since it requires breaking up command buffers, and in general self-capture generates user visible changes to the contents of the capture so it's not a complete implementation as the feature requires though.