Comment by jarrett | Hacker News Reader

Comment by jarrett | Hacker News Reader

One of the biggest headaches for me is debugging. As the author says, the facilities for reading state back out are often questionable. Even where they're not, I'd rather not spend all my time rolling my own custom OpenGL debugging tools. I'd love a cross-platform OpenGL debugger--even if it only handled basic stuff.

For example, when nothing renders, I don't want to waste an hour, staring at my code with no direction, until I realize I forgot a call to glEnableVertexAttribArray. Instead, I'd like to boot up my trusty debugger and go through a sane process of narrowing down the problem, like I do for just about every other class of bug.

Also a sane way to debug shaders would be fantastic. The usual advice is to write debug info out as color values. The fact that anyone considers that a healthy debugging strategy just illustrates how far behind graphics programming is in terms of developer friendliness.

I don't know if it's better on other APIs. OpenGL is the only one I use, because I never have occasion to develop Windows-only apps.

You should definitely check out bgfx (https://github.com/bkaradzic/bgfx). It abstracts various graphics APIs for you, making development and debugging markedly easier. It also stops you from having to deal with the complex state-machine known as GL.

If you're on an nvidia GPU, check out nvidia nsight. And this is also one problem with GL, if there are good debugging/profiling tool they often only work on one OS and/or for specific GPUs (and I hope this is where VOGL will come in and fix that).

Other then that I don't even think of OpenGL as a single standard anymore. It's more like "Nvidia GL" "AMD GL", "Intel GL", "Apple GL", etc... there is a core set of functionality which works across all implementations (and which could be cleaner), but if performance is more important then easy portability, you need to implement driver specific code paths anyway. Whether this is good or bad I haven't yet made up my mind completely. At least on GL you have an environment where GPU vendors can experiment and compete through extensions.

> if performance is more important then easy portability, you need to implement driver specific code paths anyway

I think that's fine, because as you said, it encourages GPU vendors to innovate. Plus, it probably affords more of an opportunity to squeeze every last drop of performance out of each card.

On the other hand, I'd start to get upset if we had to write card-specific code just to do the absolute basics. (Which isn't the case right now.) There are tons of apps that need only a tiny fraction of the performance a GPU offers. For those apps, it would be insane having to maintain multiple codebases just to, say, draw a box with a texture and Lambert reflectance.

Hell yes. Especially with shaders - there are some debuggers for HLSL but GLSL gets no love :-{

glslDevil is a GLSL debugger http://www.vis.uni-stuttgart.de/glsldevil/

I just gave this a try. Unfortunately when it runs my app the app will at some point crash, and the console will briefly display what went wrong but then the console exits. I can't figure out if the debugger kept a log somewhere.

Anyway, this seems closed-source. Are there any open-source equivalents?

Nevermind, it became open-source at some point: http://glsl-debugger.github.io/

As with so, so many packages, I've never gotten it to run on OS X.

How about Valve's VOGL?

https://github.com/ValveSoftware/vogl

Reply on news.ycombinator.com