PDA

View Full Version : gDEBugger new version is out. We would like your feedback



Graphic Remedy
01-27-2005, 12:39 PM
Hi All

gDEBugger version 1.2 has been released. This new version adds an interactive texture viewer, an improved HTML log file and a lot of other changes.
Please download it from www.gremedy.com (http://www.gremedy.com) and give us your comment.

We are currently releasing a new version of gDEBugger every ~ 1.5 month. We have a lot of new features and enhancements in mind, but we would like to hear your inputs on:

a. Which features would like us to improve / change?
b. Which features should be added?
c. What are the annoying things?
d. Are there bugs / usability problems that disable you from using gDEBugger?
e. Any good words :-)

I encourage you to use this page and give us your feedback.

We will do our best to make gDEBugger as useful and productive as we can.

The gDEBugger team
www.gremedy.com (http://www.gremedy.com)

Gorg
01-27-2005, 03:39 PM
It is not working very much for me right now.

The gui shows nothing but logging to file works though.

There seems to be a small problem with the images link though. Looks like mozilla does not like the .\.
file:///C:/Documents%20and%20Settings/Eric/Local%20Settings/Temp/Engine-Thursday_27_January_2005-20_21_55/.\CContext2-Texture2-LOD0-2D.tif

By the way, the image beside the texture call is an awesome feature. I have been sloppy and so I can see my random binding pattern ! :)

I would like to be able to pick a directory for the logs. I don't like to dig very deep in my directory structure.

Little less important, but I think grayscale textures should stay grayscale instead of putting the color in the red channel. Simply put the color value in all color channel would do the trick.

sqrt[-1]
01-27-2005, 05:12 PM
To :Gorg
I assume you have tried http://glintercept.nutty.org ?

I also could not get the image view to display any images.

It would probably be a good idea to allow people to save the log in text as well as html as it makes it easier when running diff programs on different runs.

Perhaps making the deirectory where the logs are save to a bit more obvious (perhaps as part of the wizard?)

I might sugges the default image save format be other than .tif, as the browsers I tried did not seem to like it much. (broken image)

Graphic Remedy
01-28-2005, 12:27 AM
Hi Gorg,


Originally posted by Gorg:
It is not working very much for me right now.

The gui shows nothing but logging to file works though. The views display the information only when the process is suspended (F6).

If the process is suspended and you still face the same problem, please let us know the following:
1. Does it happen with all views or just with some of them?
2. Do you have the same problem with the "Graphic Remedy's teapot example"?
3. Do you have a sample program reproducing the problem, which you can send us for debugging?



There seems to be a small problem with the images link though. Looks like mozilla does not like the .\.
file:///C:/Documents%20and%20Settings/Eric/Local%20Settings/Temp/Engine-Thursday_27_January_2005-20_21_55/.\CContext2-Texture2-LOD0-2D.tif
It is not a mozilla '.\' specific problem. There is a problem to display Tiff files inside the browser. The default file format was defined as tiff (I changed the default when testing the application and forgot to change it back). You can change the file format in the options dialog. The version that is currently on the web server is fixed.



By the way, the image beside the texture call is an awesome feature. I have been sloppy and so I can see my random binding pattern ! :)

I would like to be able to pick a directory for the logs. I don't like to dig very deep in my directory structure.
You can set the directory for the logs in the Debug Settings Dialog (http://www.gremedy.com/images/screenshot4.gif) (CTRL-D). We will add it into the wizard in the next version.



Little less important, but I think grayscale textures should stay grayscale instead of putting the color in the red channel. Simply put the color value in all color channel would do the trick.We will check this out.

The gDEBugger (http://www.gremedy.com) Team

Graphic Remedy
01-28-2005, 01:51 AM
Originally posted by sqrt[-1]:


I also could not get the image view to display any images.

It would probably be a good idea to allow people to save the log in text as well as html as it makes it easier when running diff programs on different runs.

Perhaps making the directory where the logs are save to a bit more obvious (perhaps as part of the wizard?)

I might suggest the default image save format be other than .tif, as the browsers I tried did not seem to like it much. (broken image)1. What have you got in the Texture Viewer when the textures could not be displayed?
2. Our html logging is very light html. It is basically text file with
instead of /n and link to the images where needed.
3. The default logs directory is the TEMP directory of the computer. As mentioned, we will add it into the wizard.
4. Fixed. The tif format was intended for 3D textures, GPGPU and cross platform use.

Regards,
The gDEBugger team

supagu
01-28-2005, 03:01 AM
- i get a crash trying to look at my system specs
- also crash when changing to "front interactive"
(and it says i could view whats being rendered step by step, dont know where this is suppost to show up?)

im wondering if you could make a special programmers library so programmers can put in say some code:

gdebugComment("some random comment");

and you can break at these points also, this would allow users to set set points so they when a new frame is occuring, or if they want to analyse functions more indepth.

some profiling settings would be nifty 2. ie. how long a gl call takes.

jide
01-28-2005, 07:33 AM
Windows 2000, Xp ???

What about other OSes ? Are there even plan to be supported ?

Here were my feedbacks.

Graphic Remedy
01-30-2005, 01:49 AM
Hi supagu



- I get a crash trying to look at my system specs
- Also crash when changing to "front interactive"
(and it says i could view whats being rendered step by step, dont know where this is suppost to show up?)


These problems are new to us. Can we get a demo of your application for testing?
If this is not possible, can we send you a test version of gDEBugger?



im wondering if you could make a special programmers library so programmers can put in say some code:
gdebugComment("some random comment");


This mechanism was proposed to us by few users. We think its a good mechanism. We will implement it in one of our coming versions.



Some profiling settings would be nifty 2. ie. how long a gl call takes.


A lot of profiling abilities will get into the next gDEBugger version. All you have to do is wait for ~1 month :)

The gDEBugger team
www.gremedy.com (http://www.gremedy.com)

Graphic Remedy
01-30-2005, 01:59 AM
Hi jide



Windows 2000, Xp ???
What about other OSes ? Are there even plan to be supported ?
gDEBugger infrastructure and GUI were written in a cross platform approach and are using cross platform components.
Since gDEBugger is a new product, we would first like to make it more robust and mature on Windows and then start porting it to other platforms.
The next platform will probably be Linux.

The gDEBugger team
http://www.gremedy.com

sqrt[-1]
01-30-2005, 02:15 PM
I did not realise that you had to pause the app to get textures to display. Once I did this, they all showed up. (you may mention this in the docs, but perhaps having a "waiting for app to pause" or something in the texture dialog if it is brought up while the app is running?)

Graphic Remedy
02-02-2005, 06:22 AM
Hi All

Thanks to this discussion item posts and emails we got from a lot of users we built a new gDEBugger version that contains a lot of bug fixes and adds support to a GREMEDY_string_marker extension.

This version can be downloaded from:
http://www.gremedy.com/download.php

String markers are text messages that can be embedded in the OpenGL calls history log of your application. This is done by using the GL_GREMEDY_string_marker OpenGL extension. String markers help you make the OpenGL calls history log more readable: you can mark any logical operation / section executed by your application with a string marker.

Examples:
glStringMarkerGREMEDY(17, "Setting up lights");
glStringMarkerGREMEDY(20, "Drawing object no 10");

Notice that the use of the OpenGL extensions mechanism enables you to add, permanently, the string markers code into your source code. This code will be activated only when you run your application with gDEBugger.

Below is the detailed version content. As far as we know, we addressed and fixed all the issues that were raised in this discussion item posts.

Added:
- GREMEDY_string_marker extension support.
- String markers are displayed in the OpenGL functions calls History View.
- String markers are displayed in the HTML calls history log file.
- String marker toolbar that allows quick navigation between the string markers logged by the OpenGL calls history log.

Changed:
- The GRTeaPot.exe example application now embeds string markers.

Fixed bugs:
- glTexSubImage3DEXT calls were not executed by gDEBugger.
- When calling glDeleteTextures with texture name = 0 or a not existing texture name, the debugged process crash.
- Calling glTexImage3DEXT or glTexImage3D generated a GL_INVALID_VALUE OpenGL error.
- Textures that have a single or double component internal format (GL_LUMINANCE, GL_LUMINANCE_ALPHA, etc) are now displayed as gray-scale images.
- Alpha textures (GL_ALPHA, GL_ALPHA4, etc) are now displayed as gray-scale images.
- The HTML log file texture image files reference used backslashes instead of slash.
- 1D texture images are now stretched to enable easier viewing of their content (Textures viewer).
- The "New workspace" wizard now displays the "Log files directory".
- The "New workspace" wizard "Swap Buffers" frame terminator was changed to "on" by default.
- gDEBugger didn't display an error when the "Log files directory" was empty and the user started debugging using the "Step" command.
- The "Texture Viewer" textures list is populated faster.
- glTexParameter calls that changed the texture border (GL_TEXTURE_BORDER_COLOR) were not logged correctly.
- The "Texture Viewer" and "Source Code Viewer" are now opened on top of other windows.
- The "Texture Viewer" "Depth slider" range was not cleared when switching from a 3D texture viewing to a 2D texture viewing.
- The "Texture Viewer" image view style was changed when viewing 3D textures.
- The "Properties View" and "Texture Viewer" now displays aid messages like: "The Views information is displayed only when the debugged process has been suspended".

As always, comments, bug reports and suggestions are welcomed.

The gDEBugger team
www.gremedy.com (http://www.gremedy.com)

arekkusu
02-02-2005, 07:02 PM
Being able to view the back/alpha/stencil/depth/aux etc buffers would be a very useful feature.

Graphic Remedy
02-03-2005, 07:27 AM
Being able to view the back/alpha/stencil/depth/aux etc buffers would be a very useful feature.

Hi arekkusu

Thanks for your input. A "Buffer Viewer" is definitely in our plans. We also plan it to show pbuffers and frame buffer objects.
Until this view is implemented, you can view the content of the back buffer by using the "Interactive Mode Toolbar". This toolbar lets you force OpenGL to draw into the front color buffer, add slow motion delay and even force the flush of the graphic pipeline after each executed OpenGL command.

The gDEBugger team
www.gremedy.com (http://www.gremedy.com)

arekkusu
02-03-2005, 09:36 AM
Another problem is incomplete enumeration listing in the HTML log:

glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, 34160.00)
glTexImage2D(GL_TEXTURE_2D, 0, 32856, ...
glClear(0x4000)

These constants should be replaced with their symbolic enumeration names.

knackered
02-03-2005, 11:23 PM
Just what bugs do you envisage gdebugger being used to solve? In all honesty, I can't think of a single time in the past where this would have been useful.

Graphic Remedy
02-04-2005, 12:05 AM
arekkusu wrote:

Another problem is incomplete enumeration listing in the HTML log:

glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, 34160.00)
glTexImage2D(GL_TEXTURE_2D, 0, 32856, ...
glClear(0x4000)

These constants should be replaced with their symbolic enumeration names.[/QUOTE]

Hi arekkusu

Thanks for the bug report. We will fix it for our next release.
Meanwhile - you can see the right values in the Texture viewer (It is already implemented there).

The gDEBugger team
www.gremedy.com (http://www.gremedy.com)

ToolTech
02-04-2005, 12:06 AM
When finding bugs in drivers it can be usefull. I send an output to nvidia with glcommands that really should work but didn't.

knackered
02-04-2005, 04:11 AM
but how would this help you in those circumstances? You know the commands you issued, you know the results you expect. gdebugger simply tells you the commands you issued, nothing more.
I'm not criticising for the sake of it, I just need someone to give me a scenario where gdebugger saves the day.
glintercept has its runtime shader editor, freeze&fly...and it's free.

Zak McKrakem
02-04-2005, 04:58 AM
I suggest you to make it not as expensive as it is now. I think that a $100-$200 price frame will boost your sales.

ToolTech
02-04-2005, 06:20 AM
I was just thinking of a scenario, where you might not be able to debug your code as it might be too complex with state changes etc.

The method to get the linear commands issued to the GPU can help you in pinpoint some bugs as you might "compile" and understand what is happening.

I don't use gdebugger but i have a system where all commands are patched and can be reported into a logg, and this helps me when i debug large scenarios in Gizmo3D wher the scene graph traversal can not be debugged with single steps..

knackered
02-04-2005, 07:37 AM
Might I suggest you simplify the actual rendering performed by your scenegraph? Is it one of those christmas trees, where you accumulate state and transforms during a traversal? That's a very inflexible system in my opinion, and as you point out, a bugger to debug.

Dirk
02-04-2005, 10:08 AM
Originally posted by knackered:
Might I suggest you simplify the actual rendering performed by your scenegraph? Is it one of those christmas trees, where you accumulate state and transforms during a traversal? That's a very inflexible system in my opinion, and as you point out, a bugger to debug.Topic Drift Alert

One of the major optimizations for scenegraph systems is rendering out-of-order: traverse the graph, collect all nodes that use the same rendering state (usually modulo transforms), change the state once and render all the nodes. Add to that optimizations to remove redundant state changes, and you get a pretty complicated system to follow without a debugger. Especially bugs in the state change minimization are really hard to find, as they usually depend on rendering order, which can change for different viewpoints with objects being culled or reordered for transparency.

End Of Topic Drift Alert

I wouldn't want to live without a GL debugger, even though right now there's no good one for Linux. But given that gDEBugger and glIntercept are promising Linux versions for the next release I'm hopeful that will change soon. ;)

knackered
02-04-2005, 12:13 PM
So you're saying the removal of redundant state changes using a state management layer on top of opengl, which is common practice, suddenly makes you require an opengl debugger? Quite frankly, the opengl layer is the last place you should be trying to trap these things!
I suppose if you're operating in an unlayered framework, with the application directly manipulating opengl state then gdebugger must be a godsend.

dirk, topic title = "gdebugger new version is out. we would like your feedback".
If this ain't feedback, I'm a monkey's uncle. Feedback you should be grateful for, as you're the one trying to sell a product on a specialist public forum, which isn't exactly cricket y'know.

zed
02-04-2005, 01:00 PM
ive made something similar myself, which lets me track openglstates, seeing if what i believe them to be and what they actually are (from glget..() commands etc).
now i havent checked out gldebugger but ive seen glIntercept, what i want is, to take a opengl state snapshot (save to file) at a particular point of time in my code, to see if what i believe to be enabled and what is actually enabled, what the shader uniforms states are etc match up. my code does this but its good to have a second opinion, is this possible with either gldebugger or glintercept?


These constants should be replaced with their symbolic enumeration names.ive got a list of these if anyone wants (GL/gl.h +glext.h ver23 plus i added gl2.0 defines recently)
might save someone some work

Dirk
02-05-2005, 03:28 PM
Originally posted by knackered:
So you're saying the removal of redundant state changes using a state management layer on top of opengl, which is common practice, suddenly makes you require an opengl debugger? Quite frankly, the opengl layer is the last place you should be trying to trap these things!
I think I have to disagree here. I work on a pretty generic scenegraph system ( OpenSG (http://www.opensg.org) ), that is used for many different applications, from visualizing gene expressions to displaying realistic car models. I usually need the debugger when one of my users sends me a problematic scene, where the typical symptom is a part of the scene changing attributes/flickering when viewed from different viewpoints. These models often contain thousands of objects with hundreds of different materials, and removing some of them makes the problem go away. These are not obvious cases where something fundamental goes wrong, but border cases where a combination of different things causes some unexpected result. In these situations it's really useful being able to log the OpenGL stream for a good and a bad frame and diff the two to see what's actually happening.

Yeah, it would be nice if it wasn't necessary to go that low, but it's comparable to being able to debug a core file after a segfault. Something unexpected happened, and you need to go to the lowest level to get more information about what's actually happening beyond "The program crashed" or "The image is wrong" before you can start hypothesizing about and start fixing the cause. I wouldn't want to work without a debugger, and that includes OpenGL. YMMV.



dirk, topic title = "gdebugger new version is out. we would like your feedback".
If this ain't feedback, I'm a monkey's uncle. Feedback you should be grateful for, as you're the one trying to sell a product on a specialist public forum, which isn't exactly cricket y'know.:confused: Sorry you got the impression I have any relation to gDEBugger, I don't. I'm not part of Gremedy, I don't even use gDEBugger because it doesn't work on Linux (yet). My off-topic was related to talking about scenegraph-specific problems in a thread about gDEBugger feedback. We can move this to the High-Level APIs forum if you want to continue discussing it.

And, honestly, feedback along the lines of "I can't think of a single time in the past where this would have been useful" is not really all that constructive to begin with.

Graphic Remedy
02-06-2005, 04:32 AM
Originally posted by zed:
... i havent checked out gldebugger but ive seen glIntercept, what i want is, to take a opengl state snapshot (save to file) at a particular point of time in my code ... is this possible with either gldebugger or glintercept?"Hi Zed

gDEBugger enables you to:
a. Save a snapshot of the entire OpenGL state machine to a file (File -> Save state variables).
b. Watch selected state variables values (OpenGL State Variables View).

The common usage is to break the application run at a place where things are OK, break it again when things are wrong, and compare the state machine values.

You can break the application run at a specific function call (example: when the application calls the OpenGL function that starts the draw of a primitive), or plant a glStringMarkerGREMEDY in your application, and mark it as a breakpoint.

The gDEBugger team
www.gremedy.com (http://www.gremedy.com)