GPGPU Debugging Tools

Thursday, September 17, 2009

Until recently, support for debugging on GPUs was fairly limited, and the features necessary for a good GPU debugger were not well defined. The advent of GPGPU programming makes it clear that a GPU debugger should have similar capabilities as traditional CPU debuggers, including variable watches, program break points, and single-step execution. GPU programs often involve user interaction. While a debugger does not need to run the application at full speed, the application being debugged should maintain some degree of interactivity [8]. A GPU debugger should be easy to add to and remove from an existing application, should mangle GPU state as little as possible, and should execute the debug code on the GPU, not in a software rasterizer. Finally, a GPU debugger should support the major GPU programming APIs and vendor-specific extensions.

There are a few different systems for debugging GPU programs available to use, but nearly all are missing one or more of the important features we just discussed.

gDEBugger [1] and GLIntercept [2] are tools designed to help debug OpenGL programs. Both are able to capture and log OpenGL state from a program. gDEBugger allows a programmer to set breakpoints and watch OpenGL state variables at runtime, as well as to profile applications using GPU hardware performance signals [8]. There is currently no specific support for debugging shaders, but both support runtime shader editing.

The Microsoft Shader Debugger [3], however, does provide runtime variable watches and breakpoints for shaders. The shader debugger is integrated into the Visual Studio IDE, and provides all the same functionality programmers are used to for traditional programming [8]. Unfortunately, debugging requires the shaders to be run in software emulation rather than on the hardware. In contrast, the Apple OpenGL Shader Builder [4] also has a sophisticated

IDE and actually runs shaders in real time on the hardware during shader debug and edit. The downside to this tool is that it was designed for writing shaders, not for computation. The shaders are not run in the context of the application, but in a separate environment designed to help facilitate shader writing.

The Shadesmith Fragment Program Debugger [5] was the first system to automate printf-style debugging while providing basic shader debugging functionality like breakpoints, program stepping, and programmable scale and bias for the image printf [8]. While Shadesmith represents a big step in the right direction for GPGPU debugging, it still has many limitations, the largest of which is that Shadesmith is currently limited to debugging assembly language shaders. Additionally, Shadesmith only works for OpenGL fragment programs, and provides no support for debugging OpenGL state.

Finally, Duca et al. recently described a system that not only provides debugging for graphics state but also both vertex and fragment programs [6]. Their system builds a database of graphics state for which the user writes SQL style queries. Based on the queries, the system extracts the necessary graphics state and program data and draws the appropriate data into a debugging window [8]. The system is build on top of the Chromium [7] library, enabling debugging of any OpenGL applications without modification to the original source program. This promising approach combines graphics state debugging and program debugging with visualizations in a transparent and hardware-rendered approach.


[1] Graphic Remedy gDEBugger., 2006.

[2] Trebilco D.: GLIntercept., 2006.

[3] Microsoft shader debugger., 2005.

[4] Apple Computer OpenGL shader builder profiler., 2006.

[5] Purcell T. J., Sen P.: Shadesmith fragment program debugger., 2003.

[6] Duca N., Niski K., Bilodeau J., Bolitho M., Chen Y., Cohen J.: A relational debugging engine for the graphics pipeline. ACM Transactions on Graphics 24, 3 (Aug. 2005), 453–463.

[7] Humphreys G., Houston M., Ng R., Frank R., Ahern S., Kirchner P., Klosowski J.:
Chromium: A stream-processing framework for interactive rendering on clusters. ACMTransactions on Graphics 21, 3 (July 2002), 693–702.

[8] Owens, J. D., Luebke, D., Govindaraju, N., Harris, M., Krüger, J., Lefohn, J. A., and Purcell, T. A Survey of General-Purpose Computation on Graphics Hardware. Computer Graphics Forum, 26(1):80–113, March 2007.


Ahsan said...

I found your content is very informative, keep writing

Anonymous said...

Dear Author !
Excuse for that I interfere … To me this situation is familiar. It is possible to discuss.

Anonymous said...

I want to quote your post in my blog. It can?
And you et an account on Twitter?

Bruno Simões said...

Feel free to do it.
Best Regards, BS