I decided to try out the new GPU debugging option with VS 2013 Professional. It was also available in VS 2012. But couldn't get a chance to try it out with 2012.
So here goes my experience. Hope this helps out anyone else interested in GPU debugging with Visual Studio.
Please Note:
I am assuming people who are reading this blog would have beginner's level knowledge about GPU debugging. If not, I would suggest getting acquainted with GPU debugging using any tools including AMD'S GPU Perf that is available for free for GPU debugging on Windows platform, or "PIX for windows" by Microsoft, before continuing to read this blog. This is not to say that this blog is of any different level. This blog is again beginners level GPU debugging with Visual Studio 2013. . This is to just inform that prior knowledge is required and can be gained using Freewares provided by GPU Chip Giants like AMD and NVIDIA and Microsoft.
Also the GPU debugging is a feature supported only in VS Pro and higher models of VS
------------------------------------------------------------------------------------------------------------
1. GPU Debugging had to be enabled for the project. I used the instructions here http://msdn.microsoft.com/en-us/library/hh873126.aspx
-The option for accelerator in my project said GPU Software Emulator though. The code was not written with accelerator::direct3d_ref accelerator in mind.
2. Ctrl+F10 (Run to Cursor) Debug option did not work as expected. Did not break anywhere, not sure if it is because the project had disabled cursor in its code, or due to some other reason.
3. Debug -> Graphics -> Start Diagnostics Started the Game, and allowed to capture frame by hitting "Print Screen" button.
4. Once the project is exited, now it is time to debug those captured frames.
5.Double clicking any frame, leads to draw calls display, for that frame. The API calls could be searched within that Graphics Events List Window.
6.Double clicking on each draw call displays RenderTarget with the objects drawn so far in the window marked "Graphics Experiment.vsglog until that draw call, like any other good GPU Debugging tool.
7.Clicking on the link ID3D11DeviceContext shows the context, textures, raster state etc in D3D11 Device Context Window.
8. The pixel shader and vertex shader did not show the source code, most likely because the shaders were not compiled with debug info.
9.I wanted to verify why a certain object did not render on screen, so I right clicked the draw call in the Graphcis Event List and invoked "Pipeline Stages" Window
10. Clicking on Vertex Shader Play button Brings up the Shader debugging window. It shows disassembly code now because the shader was not compiled for debug. Same goes for pixel shader.
11. Looks like the mesh drawn is of size 0, meaning Scale was set to 0 in code. Debugging into code, the issue was fixed happily. Thanks to VS 2013 GPU Debugging.
12. There are other cool features as well and much more to experiment with. For e.g. you can view frame rate for that frame (Vertex Shader.png -> Advanced tools -> View -> Frame Rate).
------------------------------------------------------------------------------------------------------------
All of this is pretty cool. The reasons given by Microsoft as to why we need VS GPU debugging when there is PIX for Windows (as part of DirectX SDK), is that we can also add code to capture frames, for applications that run on tablets or devices that do not have visual studio, then later debug those captured frames using Visual Studio, which sounds pretty good in terms of flexibility and in terms of game development or application development for mobile platforms. If you have tried this feature, please do share feedback on how this flexibility scores in your opinion.
One major concern would be running out of memory in VS 2013/VS 2012. Big projects that run fine in 2010 seem to crash VS in 2012/2013. High RAM consumption was always an issue with Visual Studio. But that is a altogether totally different topic. So lets not dive into that here deeper. But if you have experienced it, feel free to share your opinions on it.
Ending my blog here. I will update as much frequently as I can.
So here goes my experience. Hope this helps out anyone else interested in GPU debugging with Visual Studio.
Please Note:
I am assuming people who are reading this blog would have beginner's level knowledge about GPU debugging. If not, I would suggest getting acquainted with GPU debugging using any tools including AMD'S GPU Perf that is available for free for GPU debugging on Windows platform, or "PIX for windows" by Microsoft, before continuing to read this blog. This is not to say that this blog is of any different level. This blog is again beginners level GPU debugging with Visual Studio 2013. . This is to just inform that prior knowledge is required and can be gained using Freewares provided by GPU Chip Giants like AMD and NVIDIA and Microsoft.
Also the GPU debugging is a feature supported only in VS Pro and higher models of VS
------------------------------------------------------------------------------------------------------------
1. GPU Debugging had to be enabled for the project. I used the instructions here http://msdn.microsoft.com/en-us/library/hh873126.aspx
-The option for accelerator in my project said GPU Software Emulator though. The code was not written with accelerator::direct3d_ref accelerator in mind.
2. Ctrl+F10 (Run to Cursor) Debug option did not work as expected. Did not break anywhere, not sure if it is because the project had disabled cursor in its code, or due to some other reason.
3. Debug -> Graphics -> Start Diagnostics Started the Game, and allowed to capture frame by hitting "Print Screen" button.
4. Once the project is exited, now it is time to debug those captured frames.
5.Double clicking any frame, leads to draw calls display, for that frame. The API calls could be searched within that Graphics Events List Window.
6.Double clicking on each draw call displays RenderTarget with the objects drawn so far in the window marked "Graphics Experiment.vsglog until that draw call, like any other good GPU Debugging tool.
7.Clicking on the link ID3D11DeviceContext shows the context, textures, raster state etc in D3D11 Device Context Window.
8. The pixel shader and vertex shader did not show the source code, most likely because the shaders were not compiled with debug info.
9.I wanted to verify why a certain object did not render on screen, so I right clicked the draw call in the Graphcis Event List and invoked "Pipeline Stages" Window
10. Clicking on Vertex Shader Play button Brings up the Shader debugging window. It shows disassembly code now because the shader was not compiled for debug. Same goes for pixel shader.
11. Looks like the mesh drawn is of size 0, meaning Scale was set to 0 in code. Debugging into code, the issue was fixed happily. Thanks to VS 2013 GPU Debugging.
12. There are other cool features as well and much more to experiment with. For e.g. you can view frame rate for that frame (Vertex Shader.png -> Advanced tools -> View -> Frame Rate).
------------------------------------------------------------------------------------------------------------
All of this is pretty cool. The reasons given by Microsoft as to why we need VS GPU debugging when there is PIX for Windows (as part of DirectX SDK), is that we can also add code to capture frames, for applications that run on tablets or devices that do not have visual studio, then later debug those captured frames using Visual Studio, which sounds pretty good in terms of flexibility and in terms of game development or application development for mobile platforms. If you have tried this feature, please do share feedback on how this flexibility scores in your opinion.
One major concern would be running out of memory in VS 2013/VS 2012. Big projects that run fine in 2010 seem to crash VS in 2012/2013. High RAM consumption was always an issue with Visual Studio. But that is a altogether totally different topic. So lets not dive into that here deeper. But if you have experienced it, feel free to share your opinions on it.
Ending my blog here. I will update as much frequently as I can.
Posts
