automagic debug binding

[bryanturley]

Not really an issue, just another idea dump. I have found this debug binding to be very useful, you guys may want to implement something similar.

https://github.com/bryanturley/gl/blob/master/dbg/gl.go#L31

It doesn't do any asm/cgo directly it calls the first binding so that it can be mixed with things that don't use it. That was a first attempt, I need to make changes lower to make it generate better debug information. Took me about 30minutes to add it, all the heavy lifting is already done since you are generating funcs already. This style of debug package could replace the need for things like https://code.google.com/p/glintercept/

[bryanturley]

I was going to make a global io.Writer and change all the Printf to Fprintfs as well.

[errcw]

I started writing a simple tracing package implementation in a branch and encountered a few roadblocks:

• Creating a gl/trace sub package means that some types are unavailable, specifically DebugProc and C types. DebugProc is a surmountable quirk but I'm not sure how to cleanly handle C types.
• It's unclear we should expos the Init funcs to make the trace package a drop-in replacement for the parent package. We might want Init to optionally capture an io.Writer for creating the log thus breaking straight API compatibility.
• Go logging is relatively limited. Ultimately I wonder if we should be directing people to more robust OpenGL tooling designed for trace capture and analysis?

[bryanturley]

David Crawshaw just finish one with go.mobile, it uses build tags instead which i think is probably better than switching packages like I was doing.

https://code.google.com/p/go/source/browse/?repo=mobile#hg%2Fgl

However I would not do the defer()'ed printing. If a gl call causes your program to die immediately for whatever reason you will not get the print outs. This has happened to me with bad drivers, bad stream sync in x11, and bad error handling in the drivers. I would stick with unbuffered output, which is why I have prints before and after on functions that return.

For instance https://github.com/bryanturley/gl/blob/master/dbg/gl.go#L95

I was also intending to use 3rd party tools like https://github.com/ValveSoftware/vogl but it is nice to just have something simple as well.

[bryanturley]

Also David doesn't have a choice with GLES 2.0 but ARB_debug_output is a absurdly more useful than glError() given the async nature of opengl. Not all errors can be reported on call since you normally insert the commands into a stream that gets executed asynchronously.

No ARB_debug_output on OS X though... Apple really dropping the ball on opengl lately it requires zero hardware support.