PDA

View Full Version : gDEBugger is free!!!



Aleksandar
12-07-2010, 01:50 PM
I simply cannot believe it, but ...
gDEBugger is going to be totally free!!!
This is great news for the whole community. :)

Please, check the link:
http://www.gremedy.com/purchase.php

eodabash
12-07-2010, 02:57 PM
Wow... and considering how expensive it used to be. Can anyone venture a guess as to why they would do this?

Stephen A
12-07-2010, 04:36 PM
Awesome!

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.

Groovounet
12-07-2010, 06:20 PM
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!

skynet
12-08-2010, 03:15 AM
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...


Edit:

Ahh, never mind! There's a Licence Manager Tool where you specify the licence file :-)

ravage
12-08-2010, 03:58 AM
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.

Alfonse Reinheart
12-08-2010, 04:32 AM
was glBindTexture really deprecated at that time?

No.

ravage
12-08-2010, 04:36 AM
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.

Dark Photon
12-08-2010, 05:32 AM
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. :p It's a good product, and Graphic Remedy is responsive to support e-mails.

glDan
12-08-2010, 01:15 PM
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.

Aleksandar
12-09-2010, 11:36 AM
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.
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. ;)
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. :)

knackered
12-09-2010, 01:18 PM
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.

skynet
12-09-2010, 01:45 PM
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 :-/

Aleksandar
12-10-2010, 11:39 AM
glIntercept and nv profiler is enough for anyone.
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. :(

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? :(



http://developer.nvidia.com/object/nsight.html

Parallel Nsight Debugger for Graphics Development
Debug HLSL shaders directly on the GPU hardware. Drastically increasing debugging speed and accuracy over emulated (SW) debugging Use the familiar Visual Studio Locals, Watches, Memory and Breakpoints windows with HLSL shaders, including DirectCompute code The Debugger supports all HLSL shader types: Vertex, Pixel, Geometry, and Tessellation

Parallel Nsight Graphics Inspector for Graphics Development
Graphics Inspector captures Direct3D rendered frames for real-time examination The Frame Profiler automatically identifies bottlenecks and performance information on a per-draw call basis Pixel History shows you all operations that affected a given pixel


HLSL, HLSL, HLSL and again HLSL. And where to hell is GLSL?
I have to cool down. :(
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...

pjcozzi
12-10-2010, 03:46 PM
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 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.

Regards,
Patrick

ravage
12-10-2010, 04:19 PM
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.

overlay
12-10-2010, 10:28 PM
On the blog of the awesome book "Real-Time rendering", Eric Haines is guessing that AMD might be buying Graphic Remedy:

http://www.realtimerendering.com/blog/gdebugger-is-now-free/

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

bugmenot
12-11-2010, 07:10 AM
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.

pjcozzi
12-11-2010, 09:02 AM
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.
I ran into these crashes using an ATI card. I tried gDEBugger today on an NVIDIA card and it appears quite stable.

Patrick

vindoctor2
12-14-2010, 02:06 AM
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.

Graphic Remedy
12-15-2010, 05:54 AM
The instability with the latest ATI driver is a known issue which was already solved. The fix will be released in version 5.8 (very soon).

randall
12-15-2010, 11:19 AM
Great!

skynet
12-21-2010, 12:08 PM
I just changed my gfx card from a FirePro V5700 to a GTX470.
Now gDebugger is crashing instantly at startup... any ideas?
On the FirePro it worked quite good (apart from some crashes now and then...)

Aleksandar
12-21-2010, 02:05 PM
There must be some other problem. Maybe with your drivers. Both gDEBugger 5.7 and 5.8 work well on my GTX470 (Win7 64-bit).

Just a few facts about gDEBugger:
First, it is not quite free. The old license expires on January 31st. Second, a new license lasts about an year, but I haven't tried it yet. Third, support for ES is removed from 5.8.

skynet
12-21-2010, 03:10 PM
I found the cause:
I did not de-install ATI Sream SDK along with the drivers. Apparently, gDebugger tries to open some of these libraries which then failes, if no ATI drivers are present.
GPU-Z crashed for the same reason.

ugluk
12-22-2010, 06:47 AM
Has anyone tried this program under wine in linux? Does it work?

Dark Photon
12-22-2010, 09:30 AM
Has anyone tried this program under wine in linux? Does it work?
Yeah, been running under Linux for over a year now. Works great, except for one thing.

The last 2 versions haven't been rendering some of the GUI widgets correctly (missing some outlines on checkboxes and such). This is probably something that broke when I upgraded from openSuSE (http://www.opensuse.org) 11.2 -> 11.3. I haven't bothered to chase it down yet, but perhaps it's some interaction with different GTK versions. They deliver their own GTK libs, but maybe their start script isn't forcing them to be used and is using the system GTK libs instead. That's a guess -- like I said, I haven't really looked into it yet.

skynet
12-22-2010, 12:29 PM
Did anyone manage to get gDebugger to show any NVidia performance counters?
I use the following setup:
Windows 7 64bit
GTX470, 259.31 drivers, applies to 260.99 also
gDebugger 5.8
Perfkit 6.7 for 32bit apps

I "enabled" driver instrumentation via NVInstEnabler, but gDebugger doesn't show any NVidia specific performance counters. Sigh, will this damned PerfKit stuff _ever_ work?!

Additionally I figured that after running gDebugger, the GTX470 won't get clocked down to 2D settings anymore, resulting in a very hot gfx card and loud fan noise :-(