Hello again! Three months have passed since we talked about what's new for Graphics Development in Visual Studio 2013 Update 2. Since then the team has been working to bring even more Graphics Diagnostics features into Visual Studio. I'm very excited to share with you what we have put in Visual Studio 2013 Update 3 RC that just shipped! (Download VS 2013 Update 3 RC, Brian Harry's announcement blog post, and release notes).
Visual Studio Graphics Diagnostics (VSGD) is a tool to help diagnose graphics rendering and performance issues in DirectX apps. It can be launched by using the menu DEBUG->Graphics->Start Diagnostics or Alt+F5 on the current solution or an exe in VS. If you haven't used or read about VSGD before, Graphics Diagnostics Overview is a good start. Here is a high level summary of what's new in VSGD in VS 2013 Update 3 RC:
If you prefer to watch these features in action, check out the latest Channel9 video where I demo the following features. As a bonus, you'll also see team members who are behind this feature as well as what our offices look like in this video. J
We heard your feedback that the Capture Frame button wasn't the easiest thing to find; we heard your feedback that managing various graphics tool windows inside the VS IDE wasn't easy. So, we made a number of changes to the experience and hopefully you'll like them.
First of all, the Graphics Diagnostics tool is now running in the Performance and Diagnostics hub to provide a consistent view with other diagnostics tools you might be familiar with such as CPU Usage and Memory Usage (although the Graphics Diagnostics tool is only available via the DEBUG -> Graphics menu and cannot be started from the hub launch page). In the upper part of the session file, there is one swimlane for Frame time and another one for FPS which would give you an idea of how fast your app is running. The red line marks the threshold value which you can configure in the dropdown for each swimlane. By default it's set to 60 FPS. The bottom part lists the frames captured in the current session along with a BIG Capture Frame button in case you didn't notice. J
We also improved the experienced for analyzing frames. It has been a challenge for us to try to find a better way to help you easily manage the various graphics tool windows in the VS IDE. We explored many options for how to provide a focused environment for analyzing frames without interfering with other tasks that might be going on in the VS IDE, and so here is the new experience in Update 3 RC:
Once frames are captured, double clicking on any frame in the diagsession file, or just clicking on the Frame# link will open the frame in another instance of VS named Visual Studio Graphics Analyzer (VSGA). VSGA is a customized VS environment that only contains the necessary components for analyzing frames. It's lightweight and has a low memory footprint. It provides a familiar (it's the same VS Shell!) yet highly focused environment for analyzing frames in which you can access all the related information the same way you used to, including Event List, Pixel History, Pipeline Stage, Objects, Event Call Stack, and debugging shader code. You can also configure how VSGA looks so it's easier to distinguish it from your regular VS IDE window by using VIEW->Options page in VSGA. Notice the VSGA window in the screenshot is using the dark theme while VS is using the light theme.
You can save the diagsession file in VS or save the vsglog file in VSGA for later inspections.
The shader editing experience has also been improved with new shader Edit & Apply functionality as well as a side by side view of shader source code and compiler output disassembly code.
Clicking on the shader file name in the Pipeline Stages window or the Pixel History window will open the shader editor. On the left of the side by side view it shows the source code if available and on the right side it shows disassembly code generated by HLSL Shader Compiler. You can make changes in the source code, and once the tool detects differences in output, the Apply button at the top will be enabled. Click Apply to apply the changes to the current vsglog file and you can view how the changes impact the rendering result immediately, including Render Target view, Pipeline Stages, and Pixel History windows.
A few things to call out:
We are now exposing a number of options for capture which you can find by opening TOOLS->Options->Graphics Diagnostics page in VS. Note it's not in the VSGA IDE, which was designed for analysis only. J You can now decide whether to collect call stacks, whether to disable HUD, or whether to capture in compatibility mode.
We heard your feedback that sometimes you need to capture frames on machines that don't have VS installed. We're now shipping a command line tool for capture and playback (dxcap.exe) as part of Windows SDK. Since the Windows SDK comes with VS, you'll already have it if you install VS. You can use this tool to capture frames from desktop apps, store apps, and phone apps.
Once you installed VS 2013 Update 3 RC (Download) or standalone Windows SDK (Download). You can find dxcap.exe in C:\Windows\System32 and C:\Windows\SysWOW64. Simply pass in -c and the name of the exe to capture and –p to playback the most recent captured log.
A quick example:
To capture frame 100 from a desktop app: dxcap.exe –frame 100 -c "C:\TestProjects\MyApp.exe"
To playback: dxcap.exe -p
There are more options that can be used, such as to specify which frames to capture, whether to capture in compatibility mode, or what to use as the output filename. You can find details in DXCap's help information (Dxcap /?) or MSDN document Command-Line Capture Tool .
As always, we look forward to hearing what you think. Download Visual Studio 2013 Update 3 RC (Download), try it out, and let us know. J
The VS2013 CRT links to GetLogicalProcessorInformation, which is not available on XP SP2. The function is actually used in a few different places. In most cases this uses dynamic linking (i.e. LoadLibrary/GetProcAddress) to support XP SP2 as well. However, probably due to an oversight, the concurrency runtime component does not use dynamic linking for this particular function. That means that loading the CRT will fail even if the concurrency runtime isn't used.
Please please please consider fixing this in the RTM for Update 3. It is a trivial change and would benefit many.
(And yes, many of our customers are still on XP SP2....)
Are the diagnostics running as 32-bit, or are they running a 64-bit process elsewhere and VS interacts with it?
The shell for the diagnostics UI is a 32 bit process. However all of our work (extracting images, shader debugging, pipeline meshes, etc) is done in a 64 bit process.
When will it support OpenGL applications?
If I got it correctly, this doesn't support D3D9... Am I correct? Which versions of D3D it supports?
@Johnathan, sorry, we don't currently plans for OpenGL yet.
@JJ, you're right. This tool supports DX10&11.
Is DX11 supported when using shared surfaces with DX9 (for WPF rendering)?
I didn't get that scenario to work in previous versions (the graphics debugging never captured anything) and I'm wondering if I'm doing something wrong or if that scenario is unsupported (which would be very annoying because WPF only supports DX9 and Win8 dropped support for DX9 diagnostics!)
I would just like to pop in and also express desire for OpenGL support. Android and iOS both support OpenGL ES and not DirectX, and since I love developing on Visual Studio primarily (and then just cross compile on other environments) this is actually something that would be extremely useful.
Microsoft kind of abandoned OpenGL which has classically been a very strong option for cross platform indie developers, and though it's not the end of the world these tools aren't available for cross platform code bases, it would certainly be nice to be able to rely on Visual Studio for all my development needs.
Not upset or anything, but please mark another tally on your list of "people who want OpenGL support."
Hopefully this gets noticed here, but beginning with Update 2 for VS2013 it seems a bug was introduced in Graphics Diagnostics' Pipeline Stages window, related to the improved compute shader support that Update 2 provided. The bug still seems to be present in this Update 3 RC also:
I can only confirm it for desktop applications built for x64 targets, but interaction with the CS stage during a frame (e.g. any context->CSSet... call) appear to lock the pipeline stages window into it's compute pipeline view.
Subsequent graphics draw calls after using the compute stage display the error "The selected event has no effect or may have been occluded." rather than the expected IA/VS/PS/OM views in the Pipeline Stages window. Explicitly unbinding everything from the compute stage before any draw calls doesn't change the pipeline stages view from the above message.
However, removing absolutely all interaction with the compute stage from entire the frame allows the same draw calls to display the correct graphics pipeline stage views. That's to say, draw calls only display any pipeline views if you don't make any prior compute stage calls at all.
Thanks for any attention that can be given to this.
Did you happen to log this bug here too?
We can't repro your issue. Can you provide a project in the connect bug? Or perhaps try another machine?
It's bit off topic - but still related to vs graphics -> is it possible to extend the visual studio shader designer? E.g. adding new node types? I don't really find a lot of information on that in msdn. Imho there could be a lot more node types that would be useful.
Hi Flo P.,
The Shader Designer in Visual Studio currently isn't extensible. I've written it down for consideration for future releases. Meanwhile, can you give us a sense of what type of nodes you would like to add?
Does it work for desktop apps? Where I see lot of painting issues? To use this feature does app must be using directX for graphics or traditional MFC graphics also allow to debug?