OpenGL ES 2.0 debugging

Question

So, I have an OpenGL ES 2.0 app. It compiles and runs in the iPhone/iPad simulators, on a real iPhone/iPad, and under Windows using Imgtec's emulator libraries (i.e. PVRVframe).

In said app, I have one particular draw call that results in no pixels written to the target, even though all the state I can query looks sensible (viewport, depth test/stencil test/cull/blend off, framebuffer complete etc), and AFAICT I am submitting sensible vertex data.

What I'm after at this point is a Pix / GPAD - like tool that will let me step through the scene and review state I cannot directly query from OpenGL at the point of the draw call in question (e.g. actual vertex/index buffer content).

Neither PVRTrace nor the OSX instruments appear to capture enough state for debugging this kind of problem. In particular, they do not capture vertex/index buffer or texture data (OSX instruments doesn't capture shader source either).

gDEBugger, previously the answer to this sort of question on Stack Overflow, is now at version 5.8 - it's gone free, which is nice, but no longer supports OpenGL ES 2 (under Windows, no ES2-renderable config is available through EGL; under OSX, there is no way to attach the debugger to an app running either in the simulator or on the real device) - which is not as nice.

Am I missing something obvious? What are my options? How do others debug their scenes?

Solution 1

It's possible in Xcode since version 4.2, c.f. https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_4_2.html#//apple_ref/doc/uid/00200-SW5

Solution 2

There are several OpenGL ES 1.1/2.0 debugging tools from GPU vendors. Almost these tools require real device, but Imagination Technologies provides an emulation libraries and a tracing tool which you used. Did you use PVRTrace with PVRVFrame?

• PowerVR (Imagination Technologies)
  • PVRVFrame is an emulation libraries for OpenGL ES 1.1/2.0 on OpenGL. And GL calls can be traced by PVRTrace with GUI.
  • PVRTrace can also connect with Linux ARMv7 devices.
• Adreno (Qualcomm)
  • Adreno Profiler can trace GL calls with Adreno devices, such as Android with Snapdragon. Nexus One and many devices.
  • It can render GL calls that are executed on the target device.
  • WEBINAR: OPTIMIZE YOUR APP WITH ADRENO PROFILER
• Tegra (NVIDIA)
  • PerfHUD ES has Frame Debugger as Adreno profiler. It require Tegra Development Kit.
• Mali (ARM)
  • Mali GPU Performance Analysis Tool. It require Mali device. AFAIK, there are no Mali devices in the consumer market at the moment.

(I believe that gDEBugger 5.7 is the best tool for debugging OpenGL ES 1.1/2.0. But it is no longer available...)

Solution 3

I have found that gDebugger 5.7 for Windows IS still available here:

http://files.gremedy.com/downloads/gDEBugger-5_7.msi

I modified this URL from the one found at the top of this download page: view-source:http://www.gremedy.com/downloading.php?platform=windows32

It may be possible to access the same version for other platforms via the same trick.

An old license file is available here: http://www.geeks3d.com/20101207/3d-programming-gdebugger-advanced-opengl-debugger-now-free/

But it expired on Jan 31st, 2011.

Comments

[moonshadow]

For the record, have now solved the issue I was having; it was indeed down to state not captured by any of the aforementioned tools or querieable through OpenGL. It took a morning to track down; the issue would have been obvious with a single glance if I'd had a complete state dump. So I still want an answer, for next time :)

[moonshadow]

I've looked at PVRTrace, as I explain in my question. It doesn't capture texture or vertex/index buffer content (or maybe is unable to display it), and (less importantly) does not provide a way of stepping through a frame and displaying a particular draw call's results, as mature debuggers like Pix and GPAD do. Moreover, I have observed the state displayed in its state viewer disagreeing with that reported to code by glGet() for particular calls, and the results on screen implying it was PVRTrace that was wrong. This makes it of limited use. I don't have access to Adreno or Mali devices.

[moonshadow]

The Adreno profiler is great for profiling, but as with PVRTrace it does not capture enough state for debugging.

[moonshadow]

The Xcode capture frame facility is now mature enough for debugging almost all problems. We find we can't use it on iPad1-era devices for complex frames as the device runs out of memory, but that's certainly not an insurmountable issue. Note you must make sure that the Xcode workspace includes the OpenGL ES framework, even if you have some external process actually creating your builds (we use Jam), otherwise the frame capture facility will be disabled with no explanation - hopefully this will save someone else some time :)

[Nathan Monteleone]

gDEBugger's latest release, 5.8.1, no longer requires a license: gremedy.com/download.php

[Joseph]

Working gDebugger 5.8.1 link for Windows : yun.baidu.com/s/1jGMeSCm