You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: desktop-src/direct3dtools/dx-graphics-tools.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ This section lists tools and utilities provided for DirectX graphics.
14
14
15
15
| Topic | Description |
16
16
|-|-|
17
-
|[Getting started with PIX](pix/pix-overview.md)| Use PIX to debug and analyze applications using Direct3D 12. |
17
+
|[Getting started with PIX](pix/articles/general/pix-overview.md)| Use PIX to debug and analyze applications using Direct3D 12. |
18
18
|[Debugging DirectX apps remotely](debugging-directx-apps-remotely.md)| You can use Visual Studio and the Windows 8 SDK to debug DirectX apps remotely. |
19
19
|[Effect-compiler tool](fxc.md)| FXC (fxc.exe) is an offline tool for compiling [HLSL](/windows/desktop/direct3dhlsl/dx-graphics-hlsl) shaders for all versions of Direct3D. The tool is located at: (*SDK root*)\\Utilities\\Bin\\x86\\|
20
20
|[Direct3D diagnostics capture interface reference](vspixengine-reference.md)| This section covers APIs for the Direct3D graphics diagnostics capture interface. |
Copy file name to clipboardExpand all lines: desktop-src/direct3dtools/pix/articles/general/pix-overview.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,14 +7,14 @@ ms.date: 07/09/2024
7
7
8
8
# Get started with PIX
9
9
10
-
PIX is a debugging and profiling tool designed for game developers using Direct3D 12. You can [debug rendering issues and analyze frame performance with GPU Captures](pix-gpu-captures.md), or you can take a more [traditional profiling approach with Timing Captures](pix-timing-captures.md).
10
+
PIX is a debugging and profiling tool designed for game developers using Direct3D 12. You can [debug rendering issues and analyze frame performance with GPU Captures](../gpu-captures/pix-gpu-captures.md), or you can take a more [traditional profiling approach with Timing Captures](../timing-captures/pix-timing-captures.md).
11
11
12
-
PIX's CPU profiling capabilities work for any Windows application, and the GPU capabilities work on any application using Direct3D 12 (or Direct3D 11 via [Direct3D 11 on 12](../../direct3d12/direct3d-11-on-12.md)). That includes AI and ML workloads using [DirectML](/windows/ai/directml/dml), and games made with popular engines such as Unreal, Unity, and Godot.
12
+
PIX's CPU profiling capabilities work for any Windows application, and the GPU capabilities work on any application using Direct3D 12 (or Direct3D 11 via [Direct3D 11 on 12](~/direct3d12/direct3d-11-on-12.md)). That includes AI and ML workloads using [DirectML](/windows/ai/directml/dml), and games made with popular engines such as Unreal, Unity, and Godot.
13
13
14
14
While PIX can help you with no prior setup, you might want to check out [Instrument your app](pix-instrumenting.md) and [Configure PIX](pix-configuring.md) to ensure that you have the best experience with things such as PixEvents and debug symbols.
15
15
16
16
> [!NOTE]
17
-
> PIX is not intended to assist with Direct3D 12 API level issues, such as errors with compiling pipeline state objects. Instead, use [GPU-based validation and the Direct3D 12 debug layer](../../direct3d12/using-d3d12-debug-layer-gpu-based-validation.md).
17
+
> PIX is not intended to assist with Direct3D 12 API level issues, such as errors with compiling pipeline state objects. Instead, use [GPU-based validation and the Direct3D 12 debug layer](~/direct3d12/using-d3d12-debug-layer-gpu-based-validation.md).
18
18
19
19
## Installation
20
20
@@ -27,8 +27,8 @@ For notifications on new releases, you can subscribe to the [RSS feed for the PI
27
27
## What next?
28
28
29
29
Depending on your goals, you can either:
30
-
-[Debug rendering issues and analyze frame performance with GPU Captures](pix-gpu-captures.md), or
31
-
-[Profile CPU and GPU activity with timing captures](pix-timing-captures.md).
30
+
-[Debug rendering issues and analyze frame performance with GPU Captures](../gpu-captures/pix-gpu-captures.md), or
31
+
-[Profile CPU and GPU activity with timing captures](../timing-captures/pix-timing-captures.md).
Copy file name to clipboardExpand all lines: desktop-src/direct3dtools/pix/articles/gpu-captures/pix-custom-visualizers.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,19 +19,19 @@ By using the *Extensibility Paths* setting, you can specify any number of folder
19
19
20
20
If your visualizer shaders `#include` any file that's not sitting next to the main HLSL visualizer files, then you can use the *Extensibility Include Search Paths* setting to add search paths for those files.
21
21
22
-
22
+
23
23
24
24
## Custom texture visualizer
25
25
26
26
Assuming that you've configured paths to your visualizer shaders in the settings, you can now see your visualizers listed in the **Visualization** panel.
27
27
28
-
28
+
29
29
30
30
### Visualization panel
31
31
32
32
Once you've selected a custom visualizer from the list in the **Visualization** panel, the *Custom Visualization* section appears. From there, you can select to override the default texture format for your visualizer output. By default, the selected output format will be compatible with the pipeline view's currently selected texture. That's also where any shader compilation warnings/errors will be displayed.
33
33
34
-
34
+
35
35
36
36
### Creating a custom texture visualizer
37
37
@@ -80,7 +80,7 @@ In the example above, we declare `SelectedTexture` to point to the pipeline view
80
80
81
81
To get more information on the API, refer to the HLSL API section.
82
82
83
-
83
+
84
84
85
85
## Custom buffer visualizer
86
86
@@ -90,7 +90,7 @@ Assuming you've set up paths to your visualizer shaders in the settings, you can
90
90
91
91
From that panel, you can select any available custom visualizer, and see any warning/error messages from the shader compiler.
92
92
93
-
93
+
94
94
95
95
### Creating a custom buffer visualizer
96
96
@@ -141,7 +141,7 @@ In the example above, we access vertices declaring `Vertices` to point to the pi
141
141
142
142
To get more information on the API, refer to the HLSL API section.
143
143
144
-
144
+
You are allowed to have a single user constant block (`PixExt_Declare_UserConstants_Start` / `PixExt_Declare_UserConstants_End` pair) in your visualizer. You can add any number of constants of 3 different types, namely `int`, `uint`, `float`. For each one declared, a new entry will appear in the visualization panel to enter the desired value. `0` is the default for all constants.
Copy file name to clipboardExpand all lines: desktop-src/direct3dtools/pix/articles/gpu-captures/pix-gpu-captures.md
+9-9Lines changed: 9 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,7 +34,7 @@ More information about each event, such as the full set of API call parameters,
34
34
35
35
With a GPU capture open, switch to the Overview tab. Here you'll see some basic details about the capture.
36
36
37
-
To start profiling, you'll need to collect timing data. To do that, click the **Collect Timing Data** button at the top right of the **Events** view, or click the **Click here to start analysis and collect timing data** text in the **Timeline** view. That replays the GPU work in the capture and collect basic timing data such as Execution Durations (annotated with [PixEvents](pix-instrumenting.md), if your application has them). Once finished, you can collect additional data to be graphed in Timeline lanes, like occupancy information and other GPU-specific counters.
37
+
To start profiling, you'll need to collect timing data. To do that, click the **Collect Timing Data** button at the top right of the **Events** view, or click the **Click here to start analysis and collect timing data** text in the **Timeline** view. That replays the GPU work in the capture and collect basic timing data such as Execution Durations (annotated with [PixEvents](../general/pix-instrumenting.md), if your application has them). Once finished, you can collect additional data to be graphed in Timeline lanes, like occupancy information and other GPU-specific counters.
38
38
39
39
> [!TIP]
40
40
> For best results, don't interact with your computer while PIX is collecting timing data; and close any other applications that might be using the GPU.
@@ -55,18 +55,18 @@ Because GPUs are massively parallel and deeply pipelined, it's common for more t
55
55
56
56
The **Timeline** view displays one or more lanes showing the timing of each GPU operation. There's a separate lane containing EOP Duration data for each queue (graphics, compute, or copy) used by the game, plus a single lane showing Execution Duration data (where available) combined across all the queues.
57
57
58
-
58
+
59
59
60
60
> [!TIP]
61
-
> PIX on Windows doesn't currently overlap GPU work on different queues while analyzing timing in GPU captures. Consider taking a [Timing capture](pix-timing-captures.md) if you want to see overlapping async compute timing data. In GPU Captures, if a game uses async compute to execute rendering and compute work simultaneously, then PIX will instead measure first one and then the other. This may result in shorter reported durations for each part of the work compared to how it would execute inside the original game (due to reduced contention on the GPU) but a longer total time (due to reduced parallelization).
61
+
> PIX on Windows doesn't currently overlap GPU work on different queues while analyzing timing in GPU captures. Consider taking a [Timing capture](../timing-captures/pix-timing-captures.md) if you want to see overlapping async compute timing data. In GPU Captures, if a game uses async compute to execute rendering and compute work simultaneously, then PIX will instead measure first one and then the other. This may result in shorter reported durations for each part of the work compared to how it would execute inside the original game (due to reduced contention on the GPU) but a longer total time (due to reduced parallelization).
62
62
63
63
### GPU counters and occupancy
64
64
65
65
PIX exposes hardware-specific performance counters provided by IHVs via a GPU plugin. These counters can be enabled and collected in either the **Event List Counters** view (button to enable at top right of **Events** view) or the **Timeline Counters** view (button to enable at top right of **Timeline** view).
66
66
67
67
On some GPUs, PIX can also gather occupancy information. GPUs are usually constructed as a hierarchy of repeated blocks, where each level might share a resource. For example, an imaginary GPU might be structured like this
GPUs execute shaders by breaking up the shader work into waves (those are also called warps, or wave fronts). In the above diagram, each blue block is capable of executing one wave. Each green block could execute up to four waves.
72
72
@@ -76,7 +76,7 @@ At any time, all the green blocks might be executing a different number of waves
76
76
77
77
That's presented in PIX in the **Occupancy** lane, which shows the maximum occupancy, separated by shader stage. That's an indication of how much work the GPU is able to do in parallel—higher bars show better GPU utilization.
78
78
79
-
79
+
80
80
81
81
## Debugging rendering issues
82
82
@@ -91,9 +91,9 @@ Selecting an event in the **Events** view populates various views, notably the P
91
91
92
92
After selecting an event in the **Events** view, the **State and Pipeline** views (found in the **Pipeline** tab) show details of the Direct3D state at the time of that event. There you can view which resources are bound to the pipeline, shader code, inputs, outputs, and the currently bound rendertarget(s).
96
+
97
97
98
98
### Shader debugging
99
99
@@ -103,7 +103,7 @@ After selecting an appropriate event, and running analysis, you can debug your s
103
103
3. Clicking the **Debug Pixel** button in the **Pixel Details** view when viewing an appropriate resource (for example, SRV/UAV/RTV).
104
104
105
105
> [!TIP]
106
-
> If you're not able to see the shader source when debugging, you're likely missing debug information. Ensure you're generating the shader PDBs for your application, and that you have [configured PIX to load those PDBs](pix-configuring.md#debug-symbols).
106
+
> If you're not able to see the shader source when debugging, you're likely missing debug information. Ensure you're generating the shader PDBs for your application, and that you have [configured PIX to load those PDBs](../general/pix-configuring.md#debug-symbols).
107
107
108
108
#### Shader edit & continue
109
109
@@ -126,7 +126,7 @@ For any pixel-like resource (for example, RTVs, UAVs, or depth buffers), you can
126
126
127
127
## Caveats and miscellaneous notes
128
128
129
-
- It is not always possible for PIX to successfully take a GPU capture if a game is calling Direct3D 12 in invalid ways. PIX makes a best effort to be robust even in the case of incorrect usage patterns, but this is inevitably sometimes a case of garbage in, garbage out. If you are having difficulty taking GPU captures, then try using the [D3D12 Debug Layer and GPU-based validation](../../direct3d12/using-d3d12-debug-layer-gpu-based-validation.md) to find and fix any bad API calls.
129
+
- It is not always possible for PIX to successfully take a GPU capture if a game is calling Direct3D 12 in invalid ways. PIX makes a best effort to be robust even in the case of incorrect usage patterns, but this is inevitably sometimes a case of garbage in, garbage out. If you are having difficulty taking GPU captures, then try using the [D3D12 Debug Layer and GPU-based validation](~/direct3d12/using-d3d12-debug-layer-gpu-based-validation.md) to find and fix any bad API calls.
130
130
- Windows GPU captures are not, in general, portable across different GPU hardware and driver versions. In most cases, a capture taken on one machine will play back correctly on other similar GPUs from the same hardware family, and captures of some games may even work across GPUs from entirely different manufacturers, but it's also possible that something as trivial as a driver upgrade could break compatibility with older captures. PIX can guarantee playback will succeed only when the GPU and driver are exactly the same, so PIX will warn before starting analysis if there is not a perfect match. Proceed past that warning at your own risk.
131
131
- PIX has limited support for multiple GPUs. It will always play back GPU captures on a single adapter, regardless of how many adapters the application used. PIX allows you to select the playback adapter from a drop-down affordance in the PIX toolbar. PIX will attempt to auto-select the playback adapter if the application used only one adapter.
132
132
- For non-deterministic ExecuteIndirect workloads, you might want to enable the **Use replay-time ExecuteIndirect argument buffers** setting.
0 commit comments