Why We Think You Should Help Us

Basically, we're in a titanic battle to tame GL over here and we need your help. vogl in its current form represents around one year of intense effort by a tiny team inside of Valve, and we now believe we have enough of a beachhead established to grow the team without constantly stepping on each other's toes.

We were asked a simple question shortly after vogl's open source release: "why should I help you?" If you want to see more games on Linux then game developers are going to need much better tools for graphics (and CPU!) debugging. The existing open source tools fill important niches, but in general these tools are not focused or tuned to the needs of game developers.

We need developers and testers, so even if you can't code you can still make a big difference. Even if you're just learning OpenGL and want something fun to break while messing around between Dota2 or TF2 sessions then go ahead and do it (and then submit a bug report). Or, if you find a graphics bug in one of our Linux games then be sure to upload a vogl trace (either full-stream or a snapshot) somewhere and link to it in the bug report. vogl is still very new but it's been tested the most against Valve's own OpenGL titles (and the Steam client too).

---

The other question we get a lot: "What does vogl do that apitrace can't?" (apitrace is a open source full-stream GL tracer/replayer that is pretty much the only alternative to vogl on Linux.) Right now vogl does full-stream tracing/replaying, just like apitrace, but more importantly it can create "deep" GL state snapshots which are fully serializable and restorable to brand new GL contexts. It can create state snapshots while intercepting a game, or while replaying a trace, and the exact same code is used to do both.

The ability to create and restore state snapshots is a critical feature, because debugging large full-stream traces is awkward at best. Some game bugs we've worked on could only be reproduced after several minutes of actual gameplay, which results in impractically large 10+ gigabyte apitraces containing thousands of frames worth of GL calls. apitrace cannot "trim" these traces down in size, so they must always be played back from the very beginning each time you want to inspect the state at any place in the trace. By comparison, with vogl you can capture a single frame at any time while playing the game and just inspect the calls within that relatively tiny and much faster to replay trace file.

This snapshot concept may seem trivial but trust us, it's very hard to do in practice and there are (seemingly) countless details to get right. The GL state vector is massive, and a surprising amount of critical state is not directly reachable via plain API calls (so "shadowing" some driver state during tracing and playback is required). To make matters even more interesting, in order to retrieve all GL context state you must sometimes temporarily modify some other GL state. So unless you're very careful you can cause the traced app (or the replay) to diverge or even crash.

vogl can restore GL state from snapshots faithfully enough that it can continue playing back your app's GL calls as if nothing happened. We feel strongly that a GL debugger built on top of a non-restorable state snapshot system can't be fully trusted or tested. A proper state snapshot system can be used as the foundation of a robust GL debugger. The UI component of vogl's debugger ultimately is just a viewer/editor of state snapshot objects. State snapshots also enable a number of other interesting features, such as keyframe generation for fast seeking through large traces and hybrid "on the fly" tracing (where you hit a key and the previous X secs are recorded to a trace).