Optimizing HLSL Shaders(minimum precision) And Debug DirectX Graphic（一）

///

This section describes general-purpose strategies that you can use to optimize your shaders. You can apply these strategies to shaders that are written in any language, on any platform.

Know Where To Perform Shader Calculations

Vertex shaders perform operations that include fetching vertices and performing matrix transformation of vertex data. Typically, vertex shaders are executed once per vertex.

Pixel Shaders perform operations that include fetching texture data and performing lighting calculations. Typically, pixel shaders are executed once per pixel for a given piece of geometry.

Typically, pixels outnumber vertices in a scene, so pixel shaders execute more often than vertex shaders.

When you design shader algorithms, keep the following in mind:

• Perform calculations on the vertex shader if possible. A calculation that is performed on a pixel shader is much more expensive than a calculation that is performed on a vertex shader.
• Consider using per-vertex calculations to improve performance in situations such as dense meshes. For dense meshes, per-vertex calculations may produce results that are visually indistinguishable from results produced with per-pixel calculations.

Skip Unnecessary Instructions

In HLSL, dynamic branching provides the ability to limit the number of instructions that are executed. Therefore, dynamic branching can help speed up shader execution time. If geometry or pixels are not displayed, use dynamic branching to exit the shader or to limit instructions. For example, if a pixel is not lit, there is no point in executing the lighting algorithm.

The following table lists some cases where you can test conditions in your shader and use dynamic branching to skip unnecessary instructions. The table not comprehensive. Rather, it is intended to give you ideas for optimizing your code.

Condition to Check	Response in the Shader
Alpha check determines that a pixel will not be seen.	Skip the rest of the shader.
The pixel or geometry is fully fogged.	Skip the rest of the shader.
Skin weights are zero.	Skip bones.
Light attenuation is zero.	Skip lighting.
Non-positive Lambertian term.	Skip lighting.

Pack Variables and Interpolants

Be mindful of the space required for shader data. Pack as much information into a variable or interpolant as possible. Sometimes, the information from two variables can be packed into the memory space of a single variable.

Reduce Shader Complexity

Keep your shaders small and simple. In general, shaders with fewer instructions execute more quickly than shaders with more instructions. It is also easier to debug and optimize smaller, less complex shaders.

/

Using HLSL minimum precision

Starting with Windows 8, graphics drivers can implement minimum precision HLSL scalar data types by using any precision greater than or equal to their specified bit precision. When your HLSL minimum precision shader code is used on hardware that implements HLSL minimum precision, you use less memory bandwidth and as a result you also use less system power.

You can query for the minimum precision support that the graphics driver provides by calling ID3D11Device::CheckFeatureSupport with the D3D11_FEATURE_SHADER_MIN_PRECISION_SUPPORT value. For more info, see HLSL minimum precision support.

Declare variables with minimum precision data types

To use minimum precision in HLSL shader code, declare individual variables with types like min16float (min16float4 for a vector), min16int, min10float, and so on. With these variables, your shader code indicates that it doesn’t require more precision than what the variables indicate. But hardware can ignore the minimum precision indicators and run at full 32-bit precision. When your shader code is used on hardware that takes advantage of minimum precision, you use less memory bandwidth and as a result you also use less system power as long as your shader code doesn’t expect more precision than it specified.

You don't need to author multiple shaders that do and don't use minimum precision. Instead, create shaders with minimum precision, and the minimum precision variables behave at full 32-bit precision if the graphics driver reports that it doesn't support any minimum precision. HLSL minimum precision shaders don't work on operating systems earlier than Windows 8 so if you plan to target earlier operating systems, you'll need to author multiple shaders, some that do and others that don't use minimum precision.

 Note

Don't make data switches between different precision levels within a shader because these types of conversions are wasteful and reduce performance. The exception is that shader constants are still always 32 bit, but vendors can design graphics hardware that can freely down-convert to whatever lower precision the HLSL instruction reading might use.

By using minimum precision, you can control the precision of computations in various parts of your shader code.

The rules for HLSL minimum precision are similar to C/C++, where the types in an expression determine the precision of the operation, not the type being eventually written to.

Testing your minimum precision shader code

The reference rasterizer (D3D_DRIVER_TYPE_REFERENCE) gives you a rough idea of how minimum precision in your HLSL shader code behaves by quantizing each HLSL instruction to the specified precision. This helps you discover code that might accidentally rely on more than the minimum precision. The reference rasterizer doesn’t run any faster when your HLSL shader code uses minimum precision, but you can use it to verify the correctness of your code. WARP (D3D_DRIVER_TYPE_WARP) doesn’t support using minimum precision in HLSL shader code; WARP just runs at full 32-bit precision.

///

Visual Studio Graphics Diagnostics

 备注

This article applies to Visual Studio 2015. If you're looking for the latest Visual Studio documentation, see Visual Studio documentation. We recommend upgrading to Visual Studio 2019. Download it here

Visual StudioGraphics Diagnostics is a set of tools for recording and then analyzing rendering and performance problems in Direct3D apps. Graphics Diagnostics can be used on apps that are running locally on your Windows PC, in a Windows device emulator, or on a remote PC or device.

The Graphics Diagnostics workflow begins by capturing a record of how your app uses Direct3D—live, as it runs—so that its behavior can be analyzed immediately, shared, or saved for later. Capture sessions can be initiated and controlled manually from Visual Studio or with the command-line capture tool dxcap.exe. Capture sessions can also be initiated and controlled programmatically by using the Graphics Diagnostics capture APIs.

After a capture session has been recorded its contents can be played back by Visual Studio Graphics Analyzer at any time, recreating the captured frames by using the exact same resources and rendering commands the app used. Then, using the tools provided in the Graphics Analyzer window, any of the captured frames can be analyzed in detail. These tools can be used to examine any Direct3D API call, resource, pipeline state object, pipeline stage, or even the complete history of any pixel in a captured frame. By using these tools in concert, a rendering problem can be explored intuitively, starting from how it appears in a captured frame and drilling down to its root cause in the app's source code, shaders, or graphics assets.

To diagnose performance problems, a captured frame can be analyzed by using the Frame Analysis tool. This tool explores potential performance optimizations by automatically changing the way the app uses Direct3D and benchmarking all the variations for you. In the past, you might have made and benchmarked these kinds of changes manually just to find out which ones made a difference. With Frame Analysis, you only need to make the changes you already know will pay off.

Graphics Diagnostics helps your graphically-rich Direct3D app look and run its best.

Continue to Overview to learn more about what Visual Studio Graphics Diagnostics offers.

In This Section

Overview
Introduces the Graphics Diagnostics workflow and tools.

Getting Started
In this section, you'll learn how to install Visual Studio Graphics Diagnostics and how to start using Graphics Diagnostics with your Direct3D app.

Capturing Graphics Information
To use Graphics Diagnostics to examine a rendering problem in your app, you first record information about how the app uses DirectX. During the recording session, as your app runs normally, you capture (that is, select) the frames that you're interested in. The captures contain detailed information about how the frames are rendered. You can save the captured information as a graphics log document to examine later or share with other members of your team.

GPU Usage
To use Graphics Diagnostics to profile your app, use the GPU Usage tool. GPU usage can be used in concert with other profiling tools, such as CPU Usage, to correlate CPU and GPU activity that might contribute to performance problems in your app.

Graphics Log Document
To start the examination of a recorded graphics log, you use the Graphics Log document window to select a captured frame—or even a specific pixel—so that you can examine in detail the events (that is, the DirectX API calls) that affect it.

Frame Analysis
After you select a frame, you use Graphics Frame Analysis to examine and tune your rendering performance.

Event List
After you select a frame, you use the Graphics Event List to examine its events to determine whether they are related to the rendering problem.

State
The State window helps you understand the graphics state that is active at the time of the current event.

Pipeline Stages
In the Graphics Pipeline Stages window, you investigate how the currently selected event is processed by each stage of the graphics pipeline so that you can identify where the rendering problem first appears. Examining the pipeline stages is particularly helpful when an object doesn't appear because of an incorrect transformation, or when one of the stages produces output that doesn't match what the next stage expects.

Event Call Stack
You use the Graphics Event Call Stack to examine the call stack of the currently selected event so that you can navigate to app code that's related to the rendering problem.

Pixel History
By using the Graphics Pixel History window to analyze how the currently selected pixel is affected by the events that influenced it, you can identify the event or combination of events that cause certain kinds of rendering problems. The pixel history is particularly helpful when an object is rendered incorrectly because pixel shader output is either incorrect or has been combined incorrectly with the frame buffer, or when an object doesn't even appear because its pixels have been discarded before they reach the frame buffer.

Object Table
You use the Graphics Object Table to examine the properties and contents of specific Direct3D objects and resources that are in effect for the currently selected event. The object table can help you determine the graphics device context that's active during an event, and examine the contents of graphics resources such as constant buffers, vertex buffers, and textures.

HLSL Debugger
To examine how the shader code for the currently selected event and graphics pipeline stage behaves, you use the HLSL Debugger to step through code, examine the contents of variables, and perform other typical debugging tasks. You can also use the HLSL debugger to examine compute shader code, regardless of whether the results are further processed by the graphics pipeline or are just read back by your app.

Command-Line Capture Tool
Use the command-line capture tool to quickly capture and play back graphics information without using Visual Studio or programmatic capture. In particular, you can use the command-line capture tool for automation, or in a test environment.

Examples
Several examples demonstrate how to use the Graphics Diagnostics tools together to diagnose different kinds of rendering problems.

/

Overview of Visual Studio Graphics Diagnostics

备注

This article applies to Visual Studio 2015. If you're looking for the latest Visual Studio documentation, see Visual Studio documentation. We recommend upgrading to Visual Studio 2019. Download it here

Visual Studio Graphics Diagnostics is a set of tools for recording and then analyzing rendering and performance problems in Direct3D apps. Graphics Diagnostics can be used on apps that are running locally on your Windows PC, in a Windows device emulator, or on a remote PC or device.

Using Graphics Diagnostics to debug rendering problems

Debugging rendering problems in a graphically-rich app is not as straight-forward as starting a debugger and stepping through some code. In each frame, hundreds of thousands of unique pixels are produced, each according to a complex set of state, data, parameters, and code—of these, perhaps only a few pixels will exhibit the problem you are trying to diagnose. To complicate matters even further, the code that generates each pixel is executed on specialized hardware that processes hundreds of pixels in parallel. Traditional debugging tools and techniques—which are difficult to leverage in even lightly-threaded code—are ineffective when faced with so much data.

The Graphics Diagnostics tools in Visual Studio are designed to help you locate rendering problems by starting with the visual artifacts that indicate the problem and then tracing back to the source of the problem by focusing only on relevant shader code, pipeline stages, draw calls, resources, and device state—in the app's own source code.

DirectX version compatibility

Graphics Diagnostics supports apps that use Direct3D 12, Direct3D 11, and Direct3D 10, and provides limited support for apps that use Direct2D. It does not support apps that use earlier versions of Direct3D, DirectDraw, or other graphics APIs.

Windows 10 and Direct3D 12

Windows 10 introduces the next version of Direct3D, Direct3D 12, which is substantially different from Direct3D 10 and Direct3D 11. These differences bring DirectX back into alignment with modern graphics hardware and unleashing its full potential, but they also bring big API changes and place greater responsibility on the programmer to manage resource lifetimes and contention. Having great debugging tools is crucial to help graphics programmers make this transition, so Graphics Diagnostics in Visual Studio 2015 supports Direct3D12 right from the start. Despite the differences, Graphics Diagnostics with Direct3D 12 maintains feature-parity with Graphics Diagnostics with Direct3D 11.2, with the current exception of the Frame Analysis feature. Soon, support for Frame Analysis in Direct3D 12 will be added, followed by new diagnostics tools to help you solve new kinds of bugs you might encounter in Direct3D 12.

Windows 10 also maintains support for previous versions of Direct3D and the games and applications that rely on them. Graphics Diagnostics in Visual Studio 2015 continues to support Direct3D 10 and Direct3D 11 on Windows 10, as well as on Windows 8.1.

Windows 8.1 and Direct3D 11.2

In Windows 8.1, DirectX 11.2 introduces new features that include support for capturing graphics information through its runtime. Windows 8.1 uses the new runtime-based capture—known as robust capture—exclusively for all versions of DirectX that Windows 8.1 supports. Robust capture also supports new features of Direct3D 11.2.

Limited Direct2D support

Because Direct2D is a user-mode API that’s built on top of Direct3D, you can use Graphics Diagnostics to help debug rendering problems in apps that use Direct2D. However, because only the underlying Direct3D events are recorded instead of the higher-level Direct2D events, Direct2D events won't appear in the Graphics Event List. Also, because the relationship between Direct2D events and the resulting Direct3D events are not always clear, using Graphics Diagnostics to debug rendering problems in apps that use Direct2D is not straight forward. Still, you can use Graphics Diagnostics to get information about low-level rendering problems in apps that use Direct2D.

Graphics Diagnostics features in Visual Studio

Graphics Diagnostics has a dedicated interface—the Graphics Analyzer window—for diagnosing rendering problems, but it also adds some tools to the Visual Studio interface.

The graphics toolbar (Visual Studio)

The Graphics toolbar provides quick access to Graphics Diagnostics commands.

The Start Diagnostics button runs the app under Graphics Diagnostics. When an app is running under Graphics Diagnostics, the Capture the next rendered frame button is enabled.

Diagnostics capture interface

When you run your app under Graphics Diagnostics, Visual Studio displays a diagnostics session interface that you can use to capture frames and which also displays the current CPU and GPU load. The CPU and GPU load is displayed to help you identify frames you might want to capture due to their performance characteristics, rather than rendering errors.

This isn't the only way to capture frames though. You can also capture frames by using the programmatic capture interface, or by using the command-line capture program, dxcap.exe.

See Capturing Graphics Information for more information.

GPU Usage

Graphics Diagnostics can also profile the performance of your Direct3D app. Because profiling data would be skewed by recording details of graphics events, this is separate from capturing frames to be used examined with the Graphics Analyzer.

See GPU Usage for more information.

DirectX control panel

The DirectX control panel is a component of DirectX that you can use to change the way that DirectX behaves—for example, you can enable the debug version of the DirectX runtime components, select the kind of debug messages that are reported, and disallow certain graphics hardware capabilities from being used to emulate less-capable hardware. This level of control over DirectX can help you debug and test your DirectX app. You can access the DirectX control panel from Visual Studio.

To open the DirectX control panel

• On the menu bar, choose Debug, Graphics, DirectX Control Panel.

Graphics Analyzer

The Visual Studio Graphics Analyzer is a dedicated interface for examining rendering and performance problems in frames you've already captured. Inside Graphics Analyzer, you'll find several tools to help you explore and understand the rendering behavior of your app. Each tool exposes a different kind of information about the frame that's being inspected, and the tools are designed to be used in concert to intuitively narrow-in on the source of a rendering problem, starting from the its appearance in the framebuffer.

This illustration shows a typical layout of tools in the Graphics Analyzer.

The graphics toolbar (Graphics Analyzer)

The Graphics toolbar provides quick access to Graphics Analyzer tool windows.

Graphics log document

Inside the Graphics Analyzer, the graphics log document is the most prominent tool window. This window represents all of the frames you captured by running your app under Graphics Diagnostics. From here, you can select a different frame to examine or select a specific pixel that you want to examine with the Pixel History tool. The framebuffer image displayed in this document changes to reflect the currently selected Event so that you can see how the framebuffer is affected over time.

The Graphics Log Document is also the entry point to the Frame Analysis tool, which helps you understand the performance of a frame by changing the way certain aspects of rendering are configured and providing benchmark results to compare with the original.

Event list

Graphic events mark each Direct3D API call and user-defined event.

The Event List shows all of the graphics events that were recorded during the frame you're examining. To help you find what's important, the event list can be viewed hierarchically—with recent state-changes underneath the subsequent draw call—or as a timeline. Additionally, events are color-coded based on the queue they belong to and you can filter the list to only include the events you're interested in.

When you select an event in the list, the rest of the Graphics Analysis tools reflect the state of the frame at the time of that event. In this way, you can see the effect of any event on the GPU. For example, you can see the immediate effect of any draw call on the framebuffer, even if it becomes obscured by subsequent draw calls. Some events also have hyperlinks you can follow to see more details about its parameters or related resource objects.

Pipeline stages

Each draw call in your app goes through the graphics pipeline provided by Direct3D. At each stage in the pipeline, output from the previous stage is transformed by a small program, called a shader, and then passed to the next stage until it is finally rendered to the screen. Many rendering errors occur at the boundary between pipeline stages when the output format is different than the next stage expects, or when any one stage simply produces incorrect results. Normally, you only get the final results as you would see on your screen and you can't easily tell where in the pipeline the error occurred.

The Pipeline Stages window visualizes the result of each stage independently, so that you can more easily determine which stage a rendering problem first appears in. Once you've determined which stage that is, you can start debugging its shader right from the Pipeline Stages window.

Graphics State

Rendering operations depend on a lot of state that's typically spread across multiple objects. Many kinds of rendering problems are caused by misconfigured state.

The State window collects the state information relevant to each draw call together in one place so that it's easier to find, and also highlights the state changes that have occurred since the previous draw call.

Pixel history

In complex scenes, it's not uncommon for a pixel to be shaded multiple times in a single frame. Sometimes the earlier color is just overwritten, but other times the colors are combined together to achieve effects such as transparency. When the result of combining them together doesn't have the right appearance you can't easily tell if it's because one of the colors was incorrect, or if there's a problem with the way they were combined. Other times, an object might appear to be missing because its contribution to the pixel was rejected for some reason.

The Pixel History window visualizes the complete shader history of every pixel in the frame, including rejected contributions. For contributions that weren't rejected, it displays the raw shader results and how each new color was combined with the previous one. With this information, it's much easier to locate the source of errors in pixels that blend shader results, or when a rendered object is missing because its contribution to the pixel was incorrectly rejected.

Event call stack

Shader code isn't the only source of rendering problems in a Direct3D app, sometimes your app's source code passes the wrong parameter or doesn't configure Direct3D quite right. One kind of error that the previously discussed feature, Pixel History, can help you find is when a rendered object is missing because all its pixels have been rejected. This kind of error usually happens when you misconfigured a setting, such as the one that controls how the depth test is performed, and you can usually find your mistake somewhere in the call stack of the missing object's draw call.

The Event Call Stack window displays the complete call stack of every graphics event in the Event List, and even lets you jump to your app's source code if debugging information is available. This is a powerful tool for following an error from where it first appears, on the GPU, back to where it originated in your app's source code.

Object table

Every frame your app renders is probably backed by hundreds or even thousands of resource objects. These can include back buffers and render targets, textures, vertex buffers, index buffers, general buffers—almost everything Direct3D remembers is an object.

The Object Table displays all the objects that exist at the time of the graphics event selected in the event list. Since most objects in a typical app are textures, the event list is optimized to show details relevant to images at a glance. The Type column tells you what kind of object is in each row, and the Format column further shows the sub-type or version of the object. Other details are also shown. Some objects also have hyperlinks you can follow to view the object with a more specialized viewer, such as textures (you can view the texture as an image), or buffers (you can choose how the buffer viewer parses and displays the raw buffer bytes by defining the buffer format).

Frame analysis

Your app's graphics don't just need to be correct – they need to be fast, too. Even on less-powerful devices like laptops with integrated graphics or mobile phones. And they still need to look great too.

The Frame Analysis tool explores potential performance optimizations by automatically changing the way the app uses Direct3D and providing benchmark results for comparison. For example, Frame Analysis can enable mip-mapping on every texture, which might reveal textures that could benefit from mip-mapping but don't currently have it enabled. On hardware that supports it, Frame Analysis also presents information collected from the GPU's performance counters—this level of information can identify hardware-level performance issues, such as high numbers of texture fetch stalls or cache misses.

But Frame Analysis isn't just about going fast – it's about gaining the most performance you can while giving up the least amount of visual quality. Sometimes an expensive effect that looks great on a large display doesn't make the same impact when viewed on the small screen of a phone, where a simpler effect might look just as good without draining the battery. The automatic changes and benchmarks that Graphics Analysis provides can help you find the balance that’s right for your app across a range of devices.

//

Getting Started with Visual Studio Graphics Diagnostics

In this section you'll prepare to use Graphics Diagnostics for the first time, then you'll capture frames from a Direct3D app and examine them in the Graphics Analyzer.

Requirements

To use Graphics Diagnostics in Visual Studio 2015, you must have one of these editions:

• Visual Studio 2015 Enterprise

• Visual Studio 2015 Professional

• Visual Studio 2015 Community

  Download Visual Studio Community or compare Visual Studio editions

Windows 10 prerequisites

The optional Windows feature Graphics Tools provides the capture and playback infrastructure that's required by Graphics Diagnostics on Windows 10.

For information on installing Graphics Tools, see Install Graphics Tools for Windows 10.

Windows 8.1 prerequisites

The Windows Software Development Kit (SDK) for Windows 8.1 provides the capture and playback infrastructure that's required by Graphics Diagnostics on Windows 8.1, and supports development for Windows 8.1 and Windows 8.

Download the Windows Software Development Kit (SDK) for Windows 8.1

To use a remote playback machine that's running Windows 10 from a development machine running Windows 8.1, you must install the Windows 10 SDK on the development machine, and the optional Graphics Tools feature on the playback machine.

Install Graphics Tools for Windows 10

In Windows 10, the Graphics Diagnostics infrastructure is provided by an optional feature of Windows called Graphics Tools. This feature is required to capture and play back graphics information on Windows 10 regardless of whether the app being captured targets a previous version of windows or which version of Direct3D it uses. You can choose to install the Graphics Tools feature ahead of time; otherwise it will be installed on-demand the first time you start a Graphics Diagnostics session from Visual Studio.

To install Graphics Tools for Windows 10

1. On the Start menu, choose Settings. The Settings dialog appears.

2. In the Settings dialog, choose System, then select Installed apps from the list of system settings.

3. On the right-hand side of the Settings dialog, choose Manage optional features under Installed apps and features. The Manage optional features dialog appears.

4. In the Manage optional features dialog, choose Add a feature. A list of optional features you can install appears.

5. Select Graphics Tools from the list of features, then choose Install.

   The Graphics Tools feature is also installed automatically when you install the Windows 10 SDK.

 提示

The optional Graphics Tools feature of Windows 10 provides lightweight capture and playback functionality—such as the command-line capture program dxcap.exe—that can be used in support, testing, and diagnostic scenarios on machines where developer tools aren't installed. For more information, see the Command-Line Capture Tool topic.

Using Graphics Diagnostics for the first time

Now that you have everything you need, you're ready to start using Graphics Diagnostics. Just follow these steps.

1 - Create a Direct3D app

If you've already got your own Direct3D app to explore Graphics Diagnostics with, great! Otherwise you can use one of the Direct3D samples available on Code Gallery.

• To try out Graphics Diagnostics with Direct3D 12 on Windows 10 using Visual Studio 2015, try the Direct3D 12 UAP sample for Windows 10.

• To try out Graphics Diagnostics with Direct3D 11 on Windows 10 or Windows 8.1, you can use the DirectX App (Windows Universal) or DirectX App (Windows 8.1) project templates. Or, for something more interesting, try the DirectX marble maze game sample for Windows 8.1.

  Make sure you can build the app before moving on.

2 - Start a Graphics Diagnostics session

Now you're ready to start your first graphics diagnostics session. In Visual Studio, on the main menu, choose Debug, Graphics, Start Diagnostics, or just press Alt+F5. This starts your app under Graphics Diagnostics and displays the diagnostics session windows in Visual Studio.

 重要

If you're running your app on Windows 10 and haven't installed the optional Graphics Tools feature yet, you'll be prompted to do so now. You must install it before you can use Graphics Diagnostics on Windows 10.

3 - Capture Frames

You're ready to capture frames as soon as your app starts.

To capture single frames

• In Visual Studio, choose the Capture Frame button from the Graphics toolbar or diagnostics session window. Or, if your app has focus, just press Print Screen.

To capture a sequence of frames

• In Visual Studio, in the diagnostic session window, set Frames to capture to the number of frames you want to capture in sequence, then capture the sequence by using any of the methods you described above to capture single frames.

  To capture single frames again, set Frames to capture to 1.

  When you're done capturing frames just exit the app or choose the Stop button from the Graphics toolbar or diagnostic session window.

4 – Examine captured frames in the Graphics Analyzer

Now you're ready to examine the frames you just captured. To start analyzing a frame, choose the frame number of the frame you want to examine from the diagnostic session window. This opens the frame in the Graphics Analyzer, where you can use the Graphics Diagnostics tools to examine how your app uses Direct3D to track down rendering problems, or use the Frame Analysis tool to understand its performance.

If you selected the wrong frame from the diagnostic session window or you want to examine a different frame you can select a new one from the Graphics Analyzer. On the Render Target tab of the graphics log window, under the render target image, expand the Frame List and then choose a different frame to examine.

To learn more about how to use the Graphics Analyzer tools together, see the Examples.

//

Capturing Graphics Information

Capture graphics information from your Direct3D app so that you can use Visual Studio Graphics Analyzer to diagnose rendering problems and performance problems.

Capturing graphics information

Capturing graphics information is a two-step process. First, run your app under Graphics Diagnostics, and then specify one or more frames to capture detailed information from.

To run your app under Graphics Diagnostics

• On the menu bar, choose Debug, Graphics, Start Diagnostics. (Keyboard: Press Alt+F5)

• On the Graphics toolbar, choose the Start Diagnostics button.

  While an app is running under Graphics Diagnostics, certain kinds of graphics information is captured all the time; this includes device set up, creation of the swap-chain, creation of graphics objects and resources, and other important events that affect more than one frame. At the same time, you can capture detailed information about specific frames; this includes draw calls and compute-shader dispatches, together with the Direct3D objects and resources that support them.

To capture a frame

• In Visual Studio, on the Graphics toolbar, choose the Capture Frame button

  

  .

• On the keyboard, press Print Screen.

   备注

  While an app is running under Graphics Diagnostics, the Print Screen key can only be used to capture a frame of graphics information; it doesn't perform its regular function. This remains in effect until you have stopped capturing graphics information—usually by stopping debugging or exiting the app normally—even if another application is in focus.

• In the Visual Studio capture interface, chose the Capture Frame button located above the Diagnostic session timeline, or choose the large Capture Frame button located below the Frames per second swim-lane and to the right of any previously-captured frames. Both buttons are highlighted in the image below.

  

  When you're ready to examine the frames you've captured, start the Visual Studio Graphics Analyzer by following the Frame … link above the image thumbnails, or by double-clicking the thumbnail.

  Only whole frames can be captured, so when you initiate a capture, it’s really the graphics information from the next frame that's recorded. Recording begins immediately after the frame in which you initiated capture is presented and ends when the captured frame is presented. You can capture as many frames as you want while the app is running under Graphics Diagnostics. If you don't capture any frames, the graphics log is discarded.

  While capturing frames, Visual Studio displays the diagnostics session (.diagsession) window. If you close this window, stop debugging, or close the app, you can’t capture any more frames to that log. To capture more graphics information, you have to run the app under Graphics Diagnostics again to start a new diagnostics session.

Graphics Diagnostics Capture Options

You can configure capture to collect call stacks for all graphics events or a limited subset, disable the capture HUD, and enable or disable capture compatibility mode.

To configure Graphics Diagnostics capture options

1. On the menu bar, choose Tools, Options. The Options dialog box appears.

2. In the options category list on the left, choose Graphics Diagnostics, then configure the Graphics Diagnostics options that you want.

   Collect call stacks during capture (makes capture slower)
   Check this box to collect call stacks. By default, call stacks are not collected. To capture call stacks, make sure that the Collect call stacks during capture (makes capture slower checkbox is set to enable collection and then set either the for draw, dispatch, present, and perf markers option (default) to collect only the most important call stacks, or the for everything option to collect all call stacks. To stop collecting call stacks later, clear the Collect call stacks during capture (makes capture slower checkbox.

   Disable in-game HUD during capture
   Check this box to disable the HUD overlay that an app running under graphics diagnostics usually displays. Uncheck it to display the HUD overlay.

   Capture in compatibility mode
   Check this box to capture graphics information in compatibility mode. Capturing in compatibility mode is the default. Under compatibility mode, Direct3D won't report that the GPU supports any additional features beyond those defined in the base feature level. This prevents the app being captured from using hardware-specific extensions of the GPU its captured on and ensures that the graphics log can be played back using any GPU that supports the same or higher feature level. Uncheck this box to disable compatibility mode; logs captured with compatibility mode disabled will fail to play back on any GPU that doesn't support the same additional features that were used by the app during capture.

   Stop capture if any SDK layers errors are found
   Check this box to halt capture immediately if errors are encountered.

Capturing graphics information remotely

Graphics information can be captured from an app that's running on the local machine, or on a remote machine or device. Remote capture is supported for Windows 8.1 machines and Windows RT 8.1 devices. To capture graphics information from an app that's running remotely, configure your project for remote debugging and then run your app under Graphics Diagnostics as described earlier. The app runs on the remote machine, and the captured graphics information is recorded on your development machine.

How you configure your project for remote debugging depends on the kind of app you're developing and the programming language you're using. For information about how to configure remote debugging for a Windows Store app, see Run Windows Store apps on a remote machine. For information about how to configure remote debugging for a Windows desktop app, see Set Up Remote Debugging for a Visual Studio Project.

Later, you can use a remote machine or device to play back graphics information, regardless of where the information was captured from. For more information, see How to: Change the Graphics Diagnostics Playback Machine.

Capturing graphics information from the command line

Graphics information can be captured from an app by using a command-line tool. This tool, DXCap.exe, can quickly capture and play back graphics information without using Visual Studio or programmatic capture. In particular, you can use DXCap.exe for automation, or in a test environment. For more information about DXCap.exe, see Command-Line Capture Tool

/

GPU Usage

Use the GPU Usage tool in the Visual Studio Performance and Diagnostics Hub to better understand the high-level hardware utilization of your Direct3D app. You can use it to determine whether the performance of your app is CPU-bound or GPU-bound and gain insight into how you can use the platform's hardware more effectively. GPU Usage supports apps that use Direct3D 12, Direct3D 11, and Direct3D 10; it doesn't support other graphics APIs such as Direct2D or OpenGL.

This is the GPU Usage Report window:

Requirements

The following are requirements for using the GPU Usage tool that are in addition to Graphics Diagnostics requirements.

• A GPU and driver that support the necessary timing instrumentation.

   备注

  For more information on supported hardware and drivers, see Hardware and driver support at the end of this document.

  For more information about Graphics Diagnostics requirements, see Getting Started.

Using the GPU Usage tool

When you run your app under the GPU Usage tool, Visual Studio creates a diagnostic session that graphs high-level information about your app’s rendering performance and GPU utilization in real-time.

To start the GPU Usage tool:

1. In the main menu, choose Debug, then Performance and Diagnostics (Keyboard: Press Alt+F2).

2. In the Performance and Diagnostics hub, check the box next to GPU Usage. Optionally, check the boxes next to other tools you’re interested in. You can run several Performance and Diagnostics tools concurrently to get a fuller picture of your app’s performance.

   

    备注

   Not all Performance and Diagnostics tools can be used at the same time.

3. Choose the blue Start button at the bottom of the Performance and Diagnostics hub to run your app under the tools you selected.

   The high-level information that’s displayed in real-time includes frame timing, frame rate, and GPU utilization. Each of these pieces of information are graphed independently, but use a common time-scale so that you can easily relate between them.

   The Frame time (ms) and Frames per second (FPS) graphs contain two red, horizontal lines that represent performance targets of 60 and 30 frames per second. In the Frame time graph, your app is exceeding the performance target when the graph is below the line and missing it when the graph is above the line. For the Frames per second graph it’s the opposite – your app is exceeding the performance target when the graph is above the line and missing it when the graph is below the line. Primarily, these graphs are used to get a high-level idea of your app’s performance and to identify slow-downs that you might want to investigate -- for example, a sudden drop in frame rate or a spike in GPU Utilization.

   While your app runs under the GPU Usage tool, the diagnostics session also collects detailed information about graphics events that were executed on the GPU. This information is used to generate a more granular report of how your app utilizes the hardware. Because this report takes some time to generate from the collected information, it’s only available after the diagnostics session is done collecting information.

   When you want to look at a performance or utilization issue more closely, stop collecting performance information so that the report can be generated.

To generate and view the GPU Usage Report:

1. In the bottom portion of the diagnostics session window, choose the Stop Collection link or press Stop in the upper left-hand corner.

   

2. In the top portion of the report, select a section from one of the graphs that shows the issue you want to investigate. Your selection can be up to 3 seconds long; longer sections are truncated towards the beginning.

   

3. In the bottom portion of the report, choose the view details link in the …click here to view details of GPU usage for that range message to view a detailed timeline of your selection.

   

   This opens a new tabbed document that contains the report. The GPU Usage report helps you to see when a graphics event is started on the CPU, when it reaches the GPU, and how long it takes the GPU to execute it. This information can help you to identify bottlenecks and opportunities for increased parallelism in your code.

Using the GPU Usage report

The top portion of the GPU Usage report displays timelines for the CPU processing activity, GPU rendering activity and GPU copy activity. These timelines are divided by light-grey, vertical bars that represent the display's vsync; the frequency of the bars matches the refresh rate of one of the displays (selected by using the Display drop-down) that GPU Usage data was collected from. Because the display might have a higher refresh rate than your app's performance target there might not be a 1-to-1 relationship between vsync and the frame-rate you want your app to achieve. To meet its performance target an app must complete all processing, perform rendering, and make a Present() call at the targeted framerate, but the rendered frame will not be displayed until the next vsync after Present().

The bottom portion displays a listing of the graphics events that occurred during the time period of the report.

Here’s the GPU Usage Report window:

Selecting one of the events in the bottom portion of the report places a marker at corresponding events in the relevant timelines, typically one event on a CPU thread that represents the API call and another event on one of the GPU timelines that represents when the GPU completed the task. Likewise, selecting one of the events in a timeline highlights the corresponding event in the bottom portion of the report.When zoomed out of the timelines in the top portion of the report, only the most time-consuming events are visible. To see events that have a shorter duration, zoom into the timelines by using Ctrl + wheel on your pointing device, or the scaling control in the lower left-hand corner of the top panel. You can also drag the timeline panel’s contents to move through the recorded events.

To help you find what you’re looking for, you can filter the GPU Usage Report based on Process names, Thread IDs, and the event name; additionally, you can choose which display's refresh rate determines the vysnc lines and you can sort events hierarchically if your app uses the ID3DUserDefinedAnnotation interface to group rendering commands.

Here are more details:

Filter control	Description
Process	The name of the process you are interested in. All processes that used the GPU during the diagnostics session are included in this dropdown. The color associated with the process in this drop down is the color of the thread’s activity in the timelines below.
Thread	The thread ID that you are interested in. In a multi-threaded app, this can help you isolate particular threads that belong to the process that you’re interested in. Events associated with the selected thread are highlighted in each timeline.
Display	The number of the display whose refresh rate is displayed Note: Some drivers can be configured to present multiple physical displays as a single, large virtual display. You might see just one display listed, even if the machine has multiple displays attached.
Filter	Keywords that you are interested in. Events in the bottom portion of the report will only include those that match a keyword in whole or in part. You can specify multiple keywords by separating them with a semicolon (;).
Hierarchy Sort	A checkbox that indicates whether event hierarchies--defined through user markers--are preserved or ignored.

The list of events in the bottom portion of the GPU Usage Report displays the details of each event.

Column	Description
Event Name	The name of the graphics event. An event usually corresponds to one event in a CPU thread timeline and one event on a GPU timeline. Event names might be 'unattributed' if GPU Usage was unable to determine the name of an event. For more information, see the note below this table.
CPU Start (ns)	The time that the event was initiated on the CPU by calling a Direct3D API. The time Is measured in nanoseconds, relative to when the app started.
GPU Start (ns)	The time that the event was initiated on the GPU. The time is measured in nanoseconds, relative to when the app started.
GPU Duration (ns)	The time that the event took to complete on the GPU, in nanoseconds.
Process Name	The name of the app from which the event came.
Thread ID	The thread ID from which the event came.

 重要

Windows 8.1 is required for event attribution. Additionally, if your GPU or driver don’t support the necessary instrumentation features, all events will appear as 'unattributed'. Make sure to update your GPU driver and try again if you experience this problem. For more information, see Hardware and driver support below.

GPU Usage settings

You can configure the GPU Usage tool to postpone collection of profiling information, rather than starting to collect information as soon as the app starts. Because the size of the profiling information can be significant, this is useful when you know that slowdowns in your app’s performance won’t appear until later.

To postpone profiling from the start of the app:

1. In the main menu, choose Debug, then Performance and Diagnostics (Keyboard: Press Alt+F2).

2. In the Performance and Diagnostics hub, follow the settings link next to GPU Usage.

3. Under GPU Profiling Configuration, on the General property page, clear the Begin profiling at app start checkbox to postpone profiling.

   

 重要

Postponing profiling is not currently supported for Direct3D 12 apps.

When you postpone the collection of profiling information by using this setting, an additional link becomes available in the bottom portion of the GPU Usage tool window when you run your app under the GPU Usage tool. To start collecting profiling information, choose the Start link in the Start collecting additional detailed GPU Usage Data message.

Hardware and driver support

The following GPU hardware and drivers are supported:

Vendor	GPU Description	Driver Version Required
Intel®	4th Generation Intel® Core Processors (‘Haswell’) - Intel® HD Graphics (GT1) - Intel® HD Graphics 4200 (GT2) - Intel® HD Graphics 4400 (GT2) - Intel® HD Graphics 4600 (GT2) - Intel® HD Graphics P4600 (GT2) - Intel® HD Graphics P4700 (GT2) - Intel® HD Graphics 5000 (GT3) - Intel® Iris™ Graphics 5100 (GT3) - Intel® Iris™ Pro Graphics 5200 (GT3e)	-- (use latest drivers)
AMD®	Most since AMD Radeon™ HD 7000-series (excludes AMD Radeon™ HD 7350-7670) AMD Radeon™ GPU, AMD FirePro™ GPUs, and AMD FirePro GPU accelerators featuring Graphics Core Next (GCN) architecture. AMD® E-Series and AMD A-series Accelerated Processing Units (APUs) featuring Graphics Core Next (GCN) architecture (‘Kaveri’, ‘Kabini’, ‘Temash’ , ‘Beema’, ‘Mullins’)	14.7 RC3 or higher
NVIDIA®	Most since NVIDIA® GeForce® 400-series. NVIDIA® GeForce® GPUs, NVIDIA Quadro® GPUs and NVIDIA® Tesla™ GPU accelerators featuring Fermi™, Kepler™, or Maxwell™ architecture.	343.37 or higher

Multi-GPU configurations such as NVIDIA® SLI™ and AMD Crossfire™ are not supported at this time. Hybrid graphics setup, such as NVIDIA® Optimus™ and AMD Enduro™ are supported.

///

Graphics Log Document

The Graphics Log document is the record of graphics events that occurred while your app was running under a graphics diagnostics session. After being recorded, you can examine the log in Visual Studio Graphics Analyzer to diagnose rendering and performance problems.

This is what a graphics log document looks like in the Graphics Analyzer:

Understanding graphics log documents

By using Graphics Analyzer to examine a graphics log document, you can visualize the effects of Direct3D events on the render target that occurred during capture. You can pinpoint regions of the render target that contain unexpected output. When you select a pixel in the affected region, you can use Graphics Diagnostics to inspect it, its shaders, the Direct3D events that affected it, the application call stack that led to those events, and the DirectX objects that support those events. You can use this information to diagnose rendering problems in your game or app.

The top part of the window (Graphics Experiment.vsglog) displays the current render target output of the selected frame, and the bottom part displays a Frame List that contains thumbnail images of the captured frames.

To inspect a frame

• In the Frame List, select the frame that you want to inspect. The render target output in the top part of the graphics log document is updated to display the selected frame.

To inspect a pixel

• In the top part of the graphics log document, select the pixel that you want from the render target output. When a pixel is selected, you can use the Graphics Pixel History window to view detailed information about the selected pixel. For more information, see Pixel History.

Playback machine

Also displayed in the upper-right corner of the Frame List is the Playback Machine. The playback machine is a machine or device that is used to play back graphics events from a graphics log file during a later graphics diagnostics session. By using a different device instead of your development machine to play back captured events, you can more accurately reproduce the execution environment in which the problem occurs—for example, you can use a machine that has different graphics hardware or drivers than the ones that your development machine uses, or other kinds of devices, such as an ARM-based Windows RT tablet or Windows Phone device.

For information about how to specify a playback machine, see How to: Change the Graphics Diagnostics Playback Machine.

Graphics log summary information

When a graphics log file is the active document, the Properties window displays information about the environment that hosted the Graphics Diagnostics capture session. Several categories of information are displayed.

Direct3D Information
Lists information about the hardware and driver features of the display adapter that was used during the capture session.

Property	Description
10-bit XR High Color Format	True if 10-bit XR high-color format is supported; otherwise, False.
DirectCompute CS 4.x	True if Compute Shader 4.0 is supported; otherwise, False.
Double Precision Shaders	True if the display adapter supports double-precision (64-bit) floating-point values; otherwise, False.
Driver Command Lists	True if the driver supports command lists; otherwise, False.
Driver Concurrent Creates	True if the driver supports concurrent (asynchronous) creation; otherwise, False.
Extended Formats (BGRA, etc.)	True if extended formats like BGRA are supported; otherwise, False.
Max HW Feature Level	Displays the highest feature level that is supported by the display adapter.

Display Information
Lists information about the display adapter that was used during the capture session.

Property	Description
Description	The display adapter description string.
Display Memory	The amount of memory that's installed on the graphics adapter.
Driver Name	The name of the graphics adapter driver.
Driver Version	The version of the graphics adapter driver.
Name	The name of the graphics adapter.

Experiment File
Lists information about the experiment file that's associated with the capture session.

Property	Description
Path	The path of the .vsglog file. Note: Under legacy capture, this property is unused.

Module Information
Lists the name and version of the dynamic link libraries (DLLs) that were loaded by the app during the capture session.

System Information
Lists information about the hardware and operating system that hosted the app during the capture session.

Property	Description
Memory	The amount of memory that's installed in the computer.
OS Architecture	The target CPU architecture of the operating system.
OS Version	The operating system version.
Processor	The processor that's installed in the computer.
Target Application Architecture	The target CPU architecture of the app. This can be different than the OS Architecture.

Target Application
Lists information about the app that's the subject of the capture session.

Property	Description
Last-Modified Date/Time	The date and time that the app was built.
Path	The path of the app.
Process ID	The process ID that was given to the app.
Version	The app version.

VSG Log File
Lists information about the graphics log document.

Property	Description
Created by	The name of the app that created the graphics log document. For example, if the capture session was initiated from Visual Studio (manual capture) the value of this property is Visual Studio.
Session Start Time	The date and time that the capture session began.
Size	The size of the graphics log document.

/