PIX timing captures record information about when each piece of work was carried out by the CPU and GPU. This data is gathered in realtime while the game is running, and with minimal overhead, so you can see things like how work is distributed across CPU cores, the latency between graphics work being submitted by the CPU and executed by the GPU, and how GPU rendering workloads are overlapping with async compute.
Timing captures work best when the game has been instrumented using PIX events. If you are running a recent Insiders build of Windows 10 Creators Update, aka RS2, you can also use the SetThreadDescription API to label your threads.
Timing captures can optionally capture call stack information and/or D3D12 specific GPU timing information. This data can be useful, but enabling it increases overhead of the collection.
Timing captures support multiple ways to capture. By default timing captures are taken as continuous captures and are integrated with the System Monitor. In order to start or stop a continuous timing capture press the icon next to Start Timing Capture after setting the mode to Continuous:
Once the capture is stopped a green range will appear on the System Monitor control, which allows selection of the range of timing capture data to open:
The other option for capturing timing data is through an immediate mode capture which starts, stops and then opens the timing capture after pressing the icon next to Timing Capture:
Timing captures support multiple event list views. The CPU Order event list builds hierarchies for PIX events based on the order the events were executed on per individual thread. The GPU Order event list builds hierarchies based on the GPU start time of each event per API Context (D3D12CommandQueue) that it was executed on. The hierarchy of the GPU order events list is also displayed as a flame graph in the timeline.
The timeline has two different ways to view lanes. Per-core shows a hardware perspective by visualizing the available cores and available GPU hardware engines that are reported by the driver. Per-thread shows an API perspective by visualizing the per-thread activity of an application for the CPU and the execution of GPU work per D3D12CommandQueue.