While the dream of a graphics debugger on par with GDB or Visual Studio is one of the better sorts of dreams to have, there are many difficult challenges involved in making that dream a reality. Some of these challenges are fundamental to the task of graphics debugging while others are the result of drivers, shaders and hardware being designed with little thought to the graphics debugging process. While adding additional detail to our SIGGRAPH paper on this subject [Duca et al. 2005] is one of our goals, we also want to show how well current systems work with the basic paradigm of graphics debugging. As will be clear, some graphics systems and programming models put up hurdles that, if removed, would go a long way toward simplifying the design of a graphics debugger.Our approach to graphics debugging is meant to capture the relationships between the different types of graphics data while still being practical to use: our system works on unmodified applications and in doing so does not actually modify the application's output. We use a fake OpenGL driver derived from the Chromium software to selectively buffer and track an application's drawing calls. These captured "chunks" are then passed through a shader rewriter, rendered to an offscreen texture and read-back into CPU memory. A relational algebra language similar to SQL is then used to manipulate the obtaineyd data into a useful form. Our technique is viable viable for most OpenGL extensions and across most application/scene sizes.