gDEBugger is free!!!

I simply cannot believe it, but …
gDEBugger is going to be totally free!!!
This is great news for the whole community. :slight_smile:

Please, check the link:

Wow… and considering how expensive it used to be. Can anyone venture a guess as to why they would do this?


My guess is that the desktop version did not generate enough revenue. As far as I can tell, the mobile (iPhone) versions will still need to be purchased, which is a reasonable business model (this is similar to Unity3d, for instance).

This is just a guess, but I wouldn’t be surprised if new SKUs were to be released, with different features and capabilities.

I guess would be a revenue issue but also trouble to follow the technology progresses (Stock at OpenGL 3.2 and OpenGL ES 1.1, OpenCL announced but not release) and maybe a take over by the Khronos Group even if Graphic Remedy would continue to develop this tool.

Also the development of glslDevil is stopped (well there is still some sort of maintenance) I would really enjoy to see this tool becoming open source and see what happen.

We need some good tools!

Good News!

Das somebody know how to activate the downloadable version with the free licence? I don’t know where to copy the .grl file…


Ahh, never mind! There’s a Licence Manager Tool where you specify the licence file :slight_smile:

It’s great that it got released but it’s actually not very good with the newer versions of opengl 3.2 and above. I have a deffered rendering app running that’s just a few simple objects and it can’t catch the texture data from my fbo. Also I set up a simple cube texture and it basically tells me that the format I picked for it is probably not valid so it gives me garbage while the other parts ones just say unknown.

It also says the glBindTexture is deprecated?

I don’t think it plays well with gl3.2 and above (I’m using opengl 3.3 and it didn’t say it supported it). You can change the context so I think it’s at least perfect with opengl 3.1 and below versions not really 3.2 and above.

The one thing that I can at least count on is that the analyzing of the opengl functions I use works no problems.

by the way I wasn’t paying to much attention when opengl 3.0 - 3.1 was the highest was glBindTexture really deprecated at that time?

the truth is I think I may not have messed with it enough so maybe I’m missing something.

was glBindTexture really deprecated at that time?


sorry I meant glBindBuffer but I looked at the prev spec and no it’s not supposed to be either.

Edit: actually it thinks it’s deprecated because I bind a TBO.

Will be interesting to see what the new business model is. I did receive a note from Graphic Remedy last week stating that the next version (5.8) “is going to be a FREE version!” Hard to see them being excited if they were canning the product. So could be they plan to make gDEBugger 5.7/5.8 (with GL 3.2 support) free, but then any GL support beyond that or fixes to that (i.e. future versions) you need to pay for to help support that effort. A good way to get people hooked IMO. :stuck_out_tongue: It’s a good product, and Graphic Remedy is responsive to support e-mails.

Would have been nice to play with this, but alas, I can’t.

Anyone else with a AMD 6850 card had any luck with this program ? It does a instant crash when you try running it.

Neither glBindTexture, nor glBindBuffer are deprecated. You just didn’t read the message correctly. I saw similar message, but the reason is in fact that ID of the texture/buffer is not generated with glGen*() functions, or gDEBugger cannot find where it is defined. It is deprecated to use IDs that are not managed by OpenGL.

I agree that gDEBugger is not perfect (and is currently stuck at ver 3.2) but it can be of great help. I had a lot of complains when it was not free (although I didn’t send even a single mail, because I have always used evaluation version), but now it is far past.

Don’t bother about deprecated functionality. If you can use something with the core profile, than it is not deprecate whatever gDEBugger says. :wink:
For example: glEnableClientState() is not deprecated if you are using GL_VERTEX_ATTRIB_ARRAY_UNIFIED_NV, or GL_ELEMENT_ARRAY_UNIFIED_NV. It is the only way to enable Bindless graphics. :slight_smile:

tried it a couple of years ago. it crashed on every machine in the office. POC. I think they’ll find they won’t be even able to give it away. glIntercept and nv profiler is enough for anyone.

Are you serious? I used to use GLintercept as well. Its a good tool, but needs much more labor to get some “numbers” out of it. gDebugger does the same as GLIntercept, but much better and much more. I’m yet uncertain if it will help me to improve performance, but it does a good job to inspect state, estimate used VRAM, have a quick look into rendertargets and so on.
I never used “nv profiler” yet… what is it?

I tried to use AMD’s and NVidia’s custom performance profiling libraries before. But both failed to deliver any useful data… if they worked at all :-/

I agree with skynet, but I’ll be more radical: OpenGL profilers are still in the Stone Age! It is a shame what they can do compared to D3D counterparts. :frowning:

Do you remember GLExpert; a command-prompt dump application? And just take a look at PerfHUD. We don’t need to go any further. Also, does any one of you (OpenGL programmers) use NVIDIA Parallel Nsight? I was very exited when it was announced. But then, after installing the first beta version I cooled down. I still don’t understand why NV considers OpenGL a second-rate citizen? :frowning:

HLSL, HLSL, HLSL and again HLSL. And where to hell is GLSL?
I have to cool down. :frowning:
I’ll better stop talking about GL tools and utilities (it is hard to call them profilers), because I won’t have anything pleasant to say. gDEBugger is far away from PerfHUD, but it is more useful than any of the previously mentioned tools.

OpenGL is a very powerful API, but the lack of support makes it a hostile environment for novices.

I don’t know what exactly “nv profiler” means. If it is Compute Visual Profiler, it is a CUDA tool, not OpenGL.
Maybe by making gDEBugger free, or even open for further improvements, the things will start to go ahead…

I saw this messages too. In my case, I believe it is because the pointer argument is 0. gDebugger is right that 0 wasn’t generated with glGen*(), but it is still a valid value to pass to glBindBuffer.

I’m excited that gDebugger is free. I’ve ran into several crashes today trying to view textures, single step over glBindTexture, view VBOs, etc., but I’m willing to work around them (and/or hope for fixes) considering how useful this tool looks.


Yeah that’s what I figured. Looking back at my post I didn’t completely say what I meant which was that those functions just like you guys said were never deprecated. I also saw that it only really supported opengl 3.1 not really 3.2/3.3 and decided to ignore those messages.

I still find it useful for certain things like state redundancy and easily checking values.

I am curious what they are going to do for those who use 4.x and hope that they just take the bit more time to make it work with 3.3 since there weren’t very many functions added between 3.2 and 3.3 anyway.

On the blog of the awesome book “Real-Time rendering”, Eric Haines is guessing that AMD might be buying Graphic Remedy:

However, the actual article he is referring to is a rumor from July 2010.

i dont want start new thread. but when i start gDEBugger in system information i get

Renderer Version 1.4 (4.0.10317 Compatibility Profile Context)

when i run glxinfo i got the same 1.4 (4.0… version string
it is same as i set LIBGL_ALWAYS_INDIRECT for this i can’t run any non-FFP application.

I ran into these crashes using an ATI card. I tried gDEBugger today on an NVIDIA card and it appears quite stable.


I agree. With my AMD card, when an error happens and I have the texture viewer on, gdebugger deadlocks and I have to use the task maanger to bring everything down. I don’t have this issue with NVIDIA. I use an opengl 3.3 context. If I use an opengl 3.2 context things are a little more stable with AMD, but not as good as NVIDIA.