Improving PIX, thanks to your feedback!
Thanks to everyone who took the time to answer the PIX on Windows survey we sent out!
It’s been awesome for us to see the sheer number of responses that came in from people all over the industry who care about our product – it’s because of you that we’re constantly striving to create a premium debugging and profiling experience on PC.
We want to tell you more about the survey and upcoming improvements but first a quick note: the survey might be over, but we still want to keep hearing from you.
We look at and respond to every message we get on discord.gg/directx. And every email from when you hit the Send Feedback button at the top right goes straight to us.
No matter the issue you hit, or the feedback you want to give us, please reach out!
Let’s dive right into the feedback we heard from the survey; we’ll also cover what we’re doing based on your feedback.
Upcoming Features/Improvements in PIX
Shader debugger usability
Many respondents talked about the shader debugger. It’s clear that this is a valuable feature, but we need to keep improving its reliability. Addressing shader debugger reliability issues on our backlog is a top priority, and you can expect to see improvements with every subsequent PIX release.
We’ve also heard feedback that some shaders seem to be too large for PIX to debug successfully and we’re working on solving this too.
Shader debugger improvements
We received other feedback about the shader debugger that we will address in future releases. Improvements in the next few releases will include:
- Improvements to breakpoints in the shader debugger
- Keyboard shortcuts for stepping through the shader debugger that more closely resemble the shortcuts for stepping through Visual Studio
- Display line numbers along the left-hand margin of the shader debugger to help correlate issues with other text editors
- Allow users to sort the autos window by “recent” as well as in alphabetical order
- Show a tooltip with a variable’s current value when the variable name in a shader is hovered over
We’ve been working on improvements to our acceleration structure viewer even before we started going through survey responses, and we’re happy to report that this work will meet another prominent piece of feedback.
Now that we’ve made performance improvements to the viewer in 2108.18, we’re working on making the viewer more versatile. Expect to see much more detailed information about your Acceleration Structures in the viewer in coming releases!
Besides the feedback asking to improve the acceleration structure visualizer, we also heard several other compelling ideas to make raytracing debugging and profiling better in general. We’re going to start digging into these ideas after finishing our current acceleration structure viewer improvements.
Timing capture automation
Several respondents asked for us to add scripting functionality to PIX and we’re doing just that.
We’re working on a C# API that can be used to automate many of the common tasks that are currently only available via the PIX UI or through pixtool.exe
This automation API can be used to create custom tools that support the offline capture and analysis scenarios required in test lab environments, for example.
The API can be used to launch or attach to a process, take a timing or GPU capture, and perform GPU capture analysis. Capture document objects are provided for programmatically extracting capture data. For example, the GPU capture document can be used to extract information on resources, shaders, counter data and so on.
This API will be in a release of PIX next year.
Timing data accuracy
We’ve heard that older hardware occasionally doesn’t show accurate timing on PIX – we’re actively working with hardware vendors to address this issue in a future release.
We’ve heard a lot of feedback describing the difficulties of TDR debugging and we’ve also heard some good ideas for tackling this problem in the survey.
The survey emphasized the sheer difficulty of TDR debugging with today’s existing tools; finding new ways to do TDR debugging is now an increased priority.
To set expectations though, we expect that any path we go down will likely need substantial engineering work.
We’ve heard from several developers that they want us to think about ways to let developers more intelligently visualize waves and heard some compelling ideas for us to dig into.
Like our TDR debugging investigation, this will likely have a longer time horizon than some of the other work we’re doing in the short term to respond to the survey.
Thank you again for responding to the survey!