PDA

View Full Version : GLIntercept 0.4 = Shader edit/ free camera + more



sqrt[-1]
12-14-2004, 04:05 AM
EDIT: GLIntercept 0.41 has been released with some tiny bug fixes. Get it (and future versions) from:
http://home.swiftdsl.com.au/~radlegend/GLIntercept/ or
http://glintercept.nutty.org

GLIntercept version 0.4 is complete and before I start posting on news sites I though I would let the OpenGL.org people have first go (in case of any fatal bugs)

You can get it here: (~900Kb)
http://home.swiftdsl.com.au/~radlegend/GLIntercept/Ver0_4/GLIntercept0_4.exe
(source will be posted when I update the main website)

New features (besides bug fixes and a new plugin interface):

1) Shader editor:
Screenshot:
http://home.swiftdsl.com.au/~radlegend/GLIntercept/Ver0_4/shaderedit.png

The shader editor allows the editing of ARB/NV VP/FP/GLSL shaders/programs
at run time by simply pressing a key combination (default ctrl-shift-s). Once edited, the shader can be compiled back into the application. (Very useful if a shader is mis-behaving you can edit and dump individual textures/uniforms to the output color to see if it is valid)

Note: ATI users may have problems with the GLSL editor until they fix a few bugs.(uniform sampler retrieval is broken) (Nvidia had a few bugs like rect. textures but have already stated they will fix this soon)

2) Free Camera
Screen shot:
http://home.swiftdsl.com.au/~radlegend/GLIntercept/Ver0_4/freecam.png

The "free" camera allows the user to "fly" around the rendered scene to view what actual geometry is sent to the graphics card. This plugin relies on correct usage of the modelview matrix and its usage in all vertex programs.
(Some applications with reverse perspective matrices may need to change the key combinations as the controls will be flipped - Humus demos are the only ones I found that do this)

Default key options of note:
ctrl,shift,c - Enable/Disable the free camera keys
p - Reset camera position
o - Reset camera orientation
ctrl,shift,u - Enable/Disable back face culling
ctrl,shift,w - Enable/Disable wire frame mode
ctrl,shift,v - Enable/Disable rendering of the view frustum

i,k,j,l, - Forward/Back/Left/Right movement when in free cam mode
Num pad keys - Pith/Roll/Yaw movement when in free cam mode
Shift - Movement multiplier (settable value - default = 10x)

There are many other options that can be configured scissoring/ortho views/lighting etc

3) Extension/Version override
Screen shot: http://home.swiftdsl.com.au/~radlegend/GLIntercept/Ver0_4/extoverride.png
The extension override plugin allows the user to add/remove/replace OpenGL reported extensions. This plugin also allows the overiding of version/vender/renderer etc string. This is probably most useful for high end card users to allow them to test the low end rendering pathways without swapping cards. (or to possibly fix old broken apps that don't check the version/extension strings properly)

sqrt[-1]
12-14-2004, 04:29 AM
BTW: Here is what the next releases of GLI will contain:

GLI 0.41 - Fix any critical bugs in 0.4
GLI 0.42 - Add OGL 2.0 support (assuming I have a 2.0 driver by then)

I would also like to get your opinions on what I should do next for GLI 0.5.
On my mile long todo list:

- "Artist" shader tweak. By specifying in comments at the top of the shader files line like:
//GLIEdit- range:0.0-3.0:slider

Which specify uniform name/valid values/ control type. Then at run time all the shaders that are used have this data gathered so when a "magic key" is pressed a dialog with controls for all the uniform tweakables is presented (only for shaders on that frame). Then you can get "Artists" to adjust the shaders at runtime to get the appropiate effect. (Kinda like FX Composer except at runtime)

- Image editor - similar to the current shader editor with a "worse than MS Paint" image editor so you can put dot's or characters in textures at runtime (or load a completly new texture) Probably useful if you are wondering how a texture is tiling or if it is flipped/oriented the wrong way.

- Newbie warning plugin - Take all the common questions from these forums (GL_CLAMP/ GL_RGB and not GL_RGB8 / Ms software renderer/ VBO usage/ basic GL errors etc) and write a plugin that checks for all these types of things and displays a dialog and explaination when these events happen in code. (Problem is - getting new OpenGL people to use GLIntercept with this plugin)

- A GUI that generates the GLI config files. May help new OpenGL people with my tool.

- A Direct3D-PIX like profiling tool or a NVPerfHUD-like plugin - May wait and see what Nvidia cooks up first.

- A Linux port.

None of the above options I really need at the moment so I thoght if people want to vote (or suggest something) I'll see what I can do.

knackered
12-14-2004, 04:43 AM
Crikey! Thanks! =)

pashamol
12-14-2004, 04:57 AM
I want to have in GLIntercept some profiling tool.
Like NVPerfHud or something else maybe using NV_fence extension to get some object rendering time.

harsman
12-14-2004, 05:54 AM
Wow, very impressive! Of the future features you listed, my vote goes to to change textures. I don't care about editing, just giving you a list of thumbnails of the textures available and allowing you to choose one and change it to some default one, like maybe just a logo or some text (so you can check mirroring/tiling easily) would be great.

V-man
12-23-2004, 07:05 PM
Looking good, but I'm having some trouble.

Is it possible the dll replacement is calling glGet functions at times when no context is current?

The log is full of


GL ERROR - Function glEnable generated error GL_INVALID_ENUM
GL ERROR - Function glBindTexture generated error GL_INVALID_ENUM
GL ERROR - Function glEnable generated error GL_INVALID_ENUM
GL ERROR - Function glBindTexture generated error GL_INVALID_ENUM
GL ERROR - Function glEnable generated error GL_INVALID_ENUM
GL ERROR - Function glBindTexture generated error GL_INVALID_ENUMThe shader editor says


Awaiting other GLI command
== Command timed out -GLIntercept unresponsive (hung OpenGL app?) ==
== Unexpected command from GLIntercept ==
== Command timed out -GLIntercept unresponsive (hung OpenGL app?) ==but the program isn't hung. It does not list the GLSL shaders. I did one test with a ARBvp and ARBfp pair but it took a while for it to show them in the dialog.
Then did File-> Open Selected File name but nothing would happen. I assumed it would open one of the selected shaders.

sqrt[-1]
12-23-2004, 11:25 PM
Very strange, I have not seen this before.
the:
Awaiting other GLI command
== Command timed out -GLIntercept unresponsive (hung OpenGL app?) ==

should only happen if the editor send a command to the application but does not get any response back in about 16 seconds. I have only observed this occuring in some applications that have a modal dialog open when pressing the key combination. (also the commands are procesed on the swap buffers - so if that is not called or your frame rate is very, very low you may get that.)

I always check for a valid context before making OpenGL calls - is there any other errors in the gliLog.txt?
(are there any errors reported when running your app with just the fulldebug settings and no shader editor?)

Are you using multiple threads with multiple OpenGL contexts at once? (ie. have more than one context active at a time?) GLintercept does not support that and will complain in the log if it is attempted.

To open shaders, either double click on the shader row/number or click on the "Open" button on the shader dialog. The Open Selected Filename is used if you have a selected filename in the editing text field. (legacy as the editor can edit more than shader files - like cpp files and you select a header file name in text to open. I may take this out if it confuses people - and make it more obvious how to edit shaders.)

Also, what card are you using? (I develop on Nvidia and the simple ATI tests only had some problems with GLSL uniforms.)

Is there a possibility of a demo app(or link) you can send me with this problem? I have had zero (real) problems with all the Nvidia/3DLabs/Humus GLSL demos. Could you perhaps download a humus demo and see if you have the same problems?

There is also a minor update to version 0.41 on the website. This includes some ultra-tiny bug fixes that probably don't relate to your problem..

LaBasX2
12-24-2004, 01:32 PM
This tool seems to be pretty cool!

BTW, is there something similar for DirectX?

Humus
12-24-2004, 02:06 PM
The closest thing would be PIX in the DX SDK. It was improved quite a bit in the December Update. Unfortunately, it's not open source, so you can't do any quick 'n' dirty hacks to see what the effect is of say removing a call to glDrawPixels() etc.

V-man
12-24-2004, 04:40 PM
OK, I thought it had something to do with the frame rate. My program only updates on paint messages. It is single context. Context is not always current.

I'm using the shader version for gliConfig.ini
When the scene is empty, I get


GL Intercept Log. Version : 0.4 Compile Date: Dec 14 2004 Run on: Fri Dec 24 21:28:19 2004

================================================== =
Diagnostic: Unknown function glMultiDrawArraysEXT being logged.
Diagnostic: Unknown function glMultiDrawElementsEXT being logged.
Diagnostic: Unknown function glPointParameterfEXT being logged.
Diagnostic: Unknown function glPointParameterfvEXT being logged.
Diagnostic: Unknown function glAreTexturesResidentEXT being logged.
Diagnostic: Unknown function glBindTextureEXT being logged.
Diagnostic: Unknown function glDeleteTexturesEXT being logged.
Diagnostic: Unknown function glGenTexturesEXT being logged.
Diagnostic: Unknown function glIsTextureEXT being logged.
Diagnostic: Unknown function glPrioritizeTexturesEXT being logged.
Diagnostic: Unknown function glArrayElementEXT being logged.
Diagnostic: Unknown function glColorPointerEXT being logged.
Diagnostic: Unknown function glDrawArraysEXT being logged.
Diagnostic: Unknown function glEdgeFlagPointerEXT being logged.
Diagnostic: Unknown function glGetPointervEXT being logged.
Diagnostic: Unknown function glIndexPointerEXT being logged.
Diagnostic: Unknown function glNormalPointerEXT being logged.
Diagnostic: Unknown function glTexCoordPointerEXT being logged.
Diagnostic: Unknown function glVertexPointerEXT being logged.
Diagnostic: Unknown function glAddSwapHintRectWIN being logged.
GL ERROR - Function glGetIntegerv generated error GL_INVALID_ENUMIs the error because of my code or yours?

I tested on another program of mine with an render in infinite loop and that works better. No gl errors.

Do you use the glGet functions to check states?

sqrt[-1]
12-24-2004, 06:39 PM
Humm, only updating on paint messages ... That is somethng I did not think of. I may have to give it some though....

I am not sure if it my code or yours that is generating the error.(I call glGet a lot) Have you tried running your program with out the shader editor and with all the debug options on? (at least with ExtendedErrorLog and ThreadChecking )

It is not impossible that I am making bad OpenGL calls -but you would be only the second person to report a bug. (The first bug from someone else was not really my fault as the OpenGL spec was updated)

LaBasX2
12-25-2004, 02:38 AM
I just tried PIX, thanks for the hint Humus.

I can log all calls, but is it correct that I can't see the resources, for example the shader code or texture data?

Thanks!

V-man
12-26-2004, 06:47 PM
Hi sqrt,

You said you are creatig the shader editor as a separate process. How are you communicating between it and your dll?

I'll have to sprinkle some glGetErrors then.
I can't find the xml (or xsl?) file that is suppose to be generated.
gliConfig.ini has a line that says
LogFileName = "gliInterceptLog"
LogFormat = XML;

Maybe you should put both error log and this one together so that I'll know what call causes the error.

sqrt[-1]
12-27-2004, 02:07 PM
The process communication is performed by windows messages.

The log file is not generated as LogPerFrame is probably on. (ie press Ctrl-Shift-F to grab a single frames' worth of logging)

If you enable ExtendedErrorLog you will see all the parameters that caused the error.

The GL errors ARE embedded in the OpenGL call log. Disable the XML log (comment out the line) and disable PerFrame logging (set the Enabled flag to False) (or just use the default gliconfig.ini which is just flat text logging with basic errors reported)

Then do a search in the output log for "error".

dorbie
12-27-2004, 02:23 PM
V-man make sure it can find your headers for the function prototyping. This software does not come with all prototypes hard coded in, it does a runtime parse of .h files and can add new methods. If it's missing some functions either it can't find the headers it came with or those functions aren't in those headers and you need to add some with your own .h

My guess for your problem is that you're using EXT instead of core functions for stuff that's now in core and the shipped headers with the parser has the non EXT versions, (just a wild guess), you could add your own .h to the list of parsed headers.

One thing I noticed is that glIntercept isn't perfect when it comes to legacy stuff but has a lot of the latest features.

sqrt, you should try running occasionally on stuff like the original half-life game and maybe other earlier code if you can.

tweakoz
12-27-2004, 11:52 PM
might I also add GlIntercept is a wonderful way to perform an evil hack with maya (by intercepting the wgl function requesting a visual, forcing maya to open an RGBA framebuffer for destination alpha blending with CgFX in maya)

ok, now let the EVIL HACK comments begin ;>

mtm

sqrt[-1]
12-28-2004, 12:30 AM
dorbie:
GLIntercept does not need the headers to log the functions (infact is has no inbuilt function info) It just needs the headers to know the parameters to functions. If a unknown function is intercepted, it is still logged but without parameters. (these headers are only used for the text and XML loggers - the shader/image loggers and editors etc. don't use it)

I doubt that this is the problem here as while there a few legacy functions being called and logged, it should not be causing any gl errors. (I'll just see what happens when V-man runs with proper error logging and that should indicate where the error is)

I suppose I should update the function headers for some of the legacy stuff. (but with 300 or so extensions I was only really going to support core+ARB extensions - Though I do have the common Nvidai and ATI there as well)

V-man
12-28-2004, 10:51 AM
sqrt, thanks for the help. It is creating the xml+xsl files now.

I located the problem (and silly me), I had even put a message in my code that "the following causes a GL error".

I am not using any of those ancient EXT functions. It's because of glew.
The call that causes the GL error is

glGetIntegerv(GL_MAX_RECTANGLE_TEXTURE_SIZE_EXT, xxxxx);

and glew.h has invalid values for all the tokens for GL_EXT_texture_rectangle.

//edit// I downloaded glew 1.2.5 and it has the correct tokens.

jwatte
12-30-2004, 01:34 PM
For the record: GLIntercept is still the best Ev-AR!

harsman
01-07-2005, 06:00 AM
Sorry to resurrect this old thread, but I can't get ShaderEdit to work properly with a test app. I can evoke it just fine and edit the shaders, but as soon as I change anything in the fragment shader and hit F7, it's as if the glsl shader is disabled, I get a standard fixed function output, in this case white material and a single directional light.

Dirk
01-07-2005, 06:42 AM
The output really looks pretty cool. But I don't develop on Windows...

Is anybody working on a Linux port? I see it on the list, but pretty far down. ;)

weatx
01-07-2005, 08:43 AM
LOL, I thought this thread was new!

Anyway, very cool programs. I ran it and found out that GL_VERTEX_WEIGHT_ARRAY_EXT is an invalid enum...dunno why, it worked when I used to use it.

The FreeCam doesn't work however. I place the opengl.dll and freecam.ini(with the appropriate name of course) into my exe folder and run my prgram, but CTRL+SHIFT+C doesn't activate the Cam. The shader editor works with CTRL+SHIFT+S, so I don't know why the freecam wouldn't go.

Aaron

weatx
01-07-2005, 10:51 AM
I edited the freecam.ini and the freecam.dll part was remmed. I un-remmed it and then it worked fine.

Very cool program. I will use it much :) .

Aaron

sqrt[-1]
01-07-2005, 11:30 PM
harsman:
1) Does the shader say it compiled correctly? (by default the 3Dlabs validator is run first and then the compiler, so ensure to scroll the output window)

2) What happens if you try to "revert" a recompiled shader? (select the shader and hit the revert button)

3) Is the program a fragment+vertex, fragment only, vertex only?

4) Are there any errors in the gliLog.txt

5) Most importantly: What card/driver are you using? (There were some driver bugs on ATI with GLSL last time I tried - Nvidia seems OK and I have not tested 3Dlabs or others)

weatx:

GL_VERTEX_WEIGHT_ARRAY_EXT is probably invalid as the vertex weight extension has probably been dropped from later drivers.

dirk:
I am committed to a linux port in the next version. The hardest part will probably be that I have to learn GTK for the shader editor modifications. Send me an email if you would be interested in testing it before I release it. (I am a linux n00b)

harsman
01-08-2005, 01:51 AM
1) Yes, it compiles correctly and runs in hardware.

2) Then everything goes back to normal and I get the working, unmodified shader.

3) fragment + vertex

4) Diagnostic: Unknown function glMultiDrawArraysEXT being logged.
Diagnostic: Unknown function glMultiDrawElementsEXT being logged.
Diagnostic: Unknown function glPointParameterfEXT being logged.
Diagnostic: Unknown function glPointParameterfvEXT being logged.
Diagnostic: Unknown function glAreTexturesResidentEXT being logged.
Diagnostic: Unknown function glBindTextureEXT being logged.
Diagnostic: Unknown function glDeleteTexturesEXT being logged.
Diagnostic: Unknown function glGenTexturesEXT being logged.
Diagnostic: Unknown function glIsTextureEXT being logged.
Diagnostic: Unknown function glPrioritizeTexturesEXT being logged.
Diagnostic: Unknown function glArrayElementEXT being logged.
Diagnostic: Unknown function glColorPointerEXT being logged.
Diagnostic: Unknown function glDrawArraysEXT being logged.
Diagnostic: Unknown function glEdgeFlagPointerEXT being logged.
Diagnostic: Unknown function glGetPointervEXT being logged.
Diagnostic: Unknown function glIndexPointerEXT being logged.
Diagnostic: Unknown function glNormalPointerEXT being logged.
Diagnostic: Unknown function glTexCoordPointerEXT being logged.
Diagnostic: Unknown function glVertexPointerEXT being logged.
Diagnostic: Unknown function glAddSwapHintRectWIN being logged.

I don't actually use those, it's because I'm using GLEW. Then it warns that I don't delete the shader objects, but that's just my test program being lazy.

5) ATI Radeon 9500 Pro with the latest drivers. I'll whip up code to reload the shaders myself today and see if that works, if it doesn't we know ATI is to blame :)

sqrt[-1]
01-08-2005, 02:13 AM
OK, since you are on ATI it is probably the "unable to get uniform sampler values bug" as explained in the readme.txt. When I "re-compile" I create a new program and load in the new source(and setting attribute locations). I then bind and copy accross the uniform values whenever the old program is used. (where-ever possible) Since ATI have this bug where you cannot get the sampler values back from the origional GLSL program, all the samplers in the new program will sample from texture stage 0.

Does editing the shader to output a flat color (ie. = vec4(1.0,0.0,0.0,1.0); work?)

harsman
01-08-2005, 04:25 AM
That's what the fragment shader does!

Here is the fragment shader:


void main(void){
gl_FragColor=vec4(1.0, 0.0, 0.0, 1.0);
}and the vertex shader:


void main(void){
gl_Position=gl_ModelViewProjectionMatrix*gl_Vertex ;
}I've been out on errands, but I'm going to try reloading the shaders manually now, and if that works it's probably something relating to samplers or uniforms.

harsman
01-08-2005, 04:59 AM
Well, reloading manually in my app works, but I don't touch any uniforms at all then (the shader doesn't have any!). Maybe glIntercept is using an invalid program object? But the compile messages says it's valid... It's a great tool anyway, I'll just have to rely on reloading my shaders manually and just use your editor :)

V-man
01-13-2005, 04:53 PM
It would be nice if we could put a marker so that it would be easier to compare our source code with what we see in the xml

For example:


void RenderScene()
{
glxxxxxxxxxxxxxx();
glxxxxxxxxxxxxxx();
glxxxxxxxxxxxxxx();
glxxxxxxxxxxxxxx();

glMarker(some number);
glxxxxxxxxxxxxxx();
glxxxxxxxxxxxxxx();
glxxxxxxxxxxxxxx();
glxxxxxxxxxxxxxx();

glMarker(some number 2);

glxxxxxxxxxxxxxx();
glxxxxxxxxxxxxxx();
glxxxxxxxxxxxxxx();
glxxxxxxxxxxxxxx();

glMarker(some number 3);

SwapBuffers();
} I could use the marker numbers to find things quicker.

Are you calling glGetTexImage when I call glBindTexture?
For render to texture, it just shows a transparent square.
Maybe it's the alpha that is zero?

I need to see the textures, no matter what alpha is.

For ATI cards, glGetTexImage on cubemaps still doesn't work, so maybe you can write a workaround for this. Just render a fullscreen quad for each face, and glReadPixels.

****, this bug has existed since catalyst 1.0 or what?

sqrt[-1]
01-13-2005, 05:53 PM
First just a small update for upcoming 0.42:
-With some help from harsman I have figured out what was going wrong with ATI cards in GLSL compiling - (their uniform bug still exists tho)

-I have added in a lot of "legacy" function defintions and updated the legacy interfaces to work with games like Half-Life


Originally posted by V-man:
It would be nice if we could put a marker so that it would be easier to compare our source code with what we see in the xml
Yeah, I have though about this before. I might add this to 0.5 (no promises)



Are you calling glGetTexImage when I call glBindTexture?
For render to texture, it just shows a transparent square.
Maybe it's the alpha that is zero?

I need to see the textures, no matter what alpha is.
I call glGetTexImage if it has not been saved previouly or it has been dirtied since the last save.

If you want to ignore the alpha, change from saving the textures as PNG to JPG.

There is also a ATI bug in p-buffer render to texture (not sure if it still extists) where they seem to generate a new texture ID when a p-buffer is bound to a texture. (calling glGet to get the currently bound texture returns an unknown ID)



For ATI cards, glGetTexImage on cubemaps still doesn't work, so maybe you can write a workaround for this. Just render a fullscreen quad for each face, and glReadPixels.
****, this bug has existed since catalyst 1.0 or what?I dunno how long this bug has existed. I am reluctant to alter my code to work around it. (esp. in that manner, It would be easy to corrupt the GL state - I try not to do anything that would alter the flow of the program)

I may start actively reporting these bugs as I find them to ATI and hope for a fix.

V-man
01-14-2005, 06:35 AM
Originally posted by sqrt[-1]:

There is also a ATI bug in p-buffer render to texture (not sure if it still extists) where they seem to generate a new texture ID when a p-buffer is bound to a texture. (calling glGet to get the currently bound texture returns an unknown ID)
I don't know cause I don't do glGet calls normally.
You obviously do a lot in GLInterceptor so it shows all the problem areas.

Never mind putting a workaround for the cubemaps.

I think I have one texture that is not showing in th XML.
If I have a line like

glBindTexture(GL_TEXTURE_2D,2);

there is a small square showing the texture next to the number 2, but in one case I don't see it.

mornifle
01-14-2005, 07:35 AM
Your tool is really nice but i work on GNU/Linux. Is there any info about a GNU/Linux version ?

knackered
01-14-2005, 11:08 AM
He uses windows messages for IPC, so I doubt it's a small job to convert to *nix.
Anyway, glIntercept is mainly useful for catching logical errors (incorrect enums, inefficient culling etc.), so just test your application on windows using glIntercept to ensure you're not making any logical errors in your GL code, and then if you get problems running on linux you know it's a driver/environment issue rather than your application.

Dirk
01-14-2005, 02:45 PM
Originally posted by knackered:
... just test your application on windows using glIntercept to ensure you're not making any logical errors in your GL code, and then if you get problems running on linux you know it's a driver/environment issue rather than your application.That assumes that you're able and willing to compile and run your app under Windows, which is not always the case. ;)

He mentioned that he wants to do the Linux port for the next version. I'm willing to help to actually make it happen, but I agree with you that it's not going to be trivial. More help welcome...

sqrt[-1]
01-14-2005, 02:46 PM
See about 10 posts above for the linux port info.
I will have at least the main logging/error checking capability in linux for the next version. The runtime shader editor may take a bit longer.

dmoc
01-17-2005, 04:42 AM
I use glLoadName(some-large-num) as markers. Great program!

Dirk
01-17-2005, 12:45 PM
Originally posted by V-man:
It would be nice if we could put a marker so that it would be easier to compare our source code with what we see in the xml
I like the idea, but I would prefer the marker to be a string (makes it easier to actually understand what's going on).

There are some functions that could be hacked to do it (use glListBase(1000000); to mark the next glCallLists() as a marker or something like that), but the clean solution would be an extension. You could use your existing extension handling framework for initializing it, and you'd only have to call the functions whenever you're actually running in the debugger.

It would probably be pretty simple to define, as it doesn't have to do much, but it would be pretty useful for debugging things. This could also be used for profilers or stuff like that, to better differentiate between different phases/parts of the rendering.

Dirk
01-17-2005, 01:39 PM
Originally posted by dirk:
It would probably be pretty simple to define, as it doesn't have to do much, but it would be pretty useful for debugging things. This could also be used for profilers or stuff like that, to better differentiate between different phases/parts of the rendering.Just for the heck of it I wrote a definition of the extension. It's here (http://www.vrac.iastate.edu/~dreiners/XXX_comment.txt) . For now this just something quickly thrown together to have something to talk about, and by no means close to being done.

But in the long run it would be nice if this or something like this was supported by all the different debuggers, and maybe even by the debugging versions of the drivers.

V-man
01-17-2005, 06:00 PM
OK, strings would work for me, but I think there is no need to have a GL specification because it's not a graphics feature.

All that is needed is a slightly modified gl header, maybe call it gl_debug.h, lib, and dll

>I use glLoadName(some-large-num) as markers. Great program!

I want the string version more for obvious reasons.

sqrt[-1]
01-18-2005, 02:18 AM
V-Man: The latest ATI drivers (Cat5.1) seems to fix the cubemap issue.

Dirk
01-18-2005, 09:20 AM
Originally posted by V-man:
OK, strings would work for me, but I think there is no need to have a GL specification because it's not a graphics feature.

All that is needed is a slightly modified gl header, maybe call it gl_debug.h, lib, and dll
I'd rather have an extension that's only supported by the debugger. This makes it much easier to debug an existing program and just generate the messages dynamically without having to recompile anything. And changing system headers is just a big no-no in my book. ;) Everybody has extension handling scaffolding anyway, making it relatively easy to add something like this.

(ed): I don't think this should ever become part of the official OpenGL spec, but an extension description just makes it easy to read and understand.

V-man
01-19-2005, 06:48 AM
Originally posted by dirk:
[QUOTE]I'd rather have an extension that's only supported by the debugger. This makes it much easier to debug an existing program and just generate the messages dynamically without having to recompile anything. And changing system headers is just a big no-no in my book. ;) Everybody has extension handling scaffolding anyway, making it relatively easy to add something like this.
You have to recompile a release version anyway, if that's what you mean.

Then a new glext.h will be needed :)

Either way, it doesn't change my part of the work .

zed
01-19-2005, 10:14 AM
excellant application!!

noticed this though
Diagnostic: Unknown function glPointParameteri being logged.
Diagnostic: Unknown function glPointParameteriv being logged.

also i didnt notice any way i can get a final count of the number of each function called

i also log them myself in my program so i wanna see if the two figures match

edit - had a look at the spec, seems like the int versions of point parameters werent in the original arb version of point parameters but are now part of the base spec

Dirk
01-19-2005, 10:27 AM
Originally posted by V-man:
You have to recompile a release version anyway, if that's what you mean.
Hm, not sure I understand you here.

My point was that you can just compile this into your regular debug version (or even into your release version, if your extension handling is efficient) and just leave it in there. Only when you run using the debugger will it do anything.

If you use a different gl.h, you will have to recompile it when you want to run the debugger (as the normal drivers don't have the glComment() call), and that can be pretty painful just for a quick check whether your GL calls are correct. And then you have to recompile it against the normal gl.h to run it using normal drivers again.

Using an extension makes the whole thing dynamic, so it will work with the regular drivers and the debugging drivers.

sqrt[-1]
01-20-2005, 12:38 AM
Originally posted by zed:
excellant application!!

noticed this though
Diagnostic: Unknown function glPointParameteri being logged.
Diagnostic: Unknown function glPointParameteriv being logged.

also i didnt notice any way i can get a final count of the number of each function called

i also log them myself in my program so i wanna see if the two figures match

edit - had a look at the spec, seems like the int versions of point parameters werent in the original arb version of point parameters but are now part of the base specUpdate done for next version.
In the meantime you can just add the following lines to <install dir>\GLFunctions\GLCore\GLCore1_4_Include.h

void glPointParameteri (GLenum[Main] pname, GLint param);
void glPointParameteriv (GLenum[Main] pname, GLint *params);

and it will pick up those entry points.

V-man
01-20-2005, 06:27 PM
Originally posted by dirk:
Hm, not sure I understand you here.
I would be using preprocessor directives, so I can choose not to compile the marker codes and other things.

I think you are thinking of something like

if extension supported
glMarker(...)
endif

Dirk
01-21-2005, 09:49 AM
Originally posted by V-man:
I would be using preprocessor directives, so I can choose not to compile the marker codes and other things.

I think you are thinking of something like

if extension supported
glMarker(...)
endif[/QB]Ok, that's what I thought. Which means you will have to compile a specific version that can only be run under the gldebugger. I'm trying to avoid that and have a version that can run using standard drivers or the debugger.

I've got some feedback from Yaki Tebeka (gdebugger) and have an updated version of my proposal here (http://www.vrac.iastate.edu/~dreiners/EXT_string_marker.txt) .

V-man
01-21-2005, 12:40 PM
Not sure what you changed, but you might want to add support for unicode. I think glProgramString had a parameter for that, although it wasn't put to use.

grisha
02-07-2005, 09:48 AM
I have small problem with glIntersept 0.41 -
If I use glew to initialize extensions I receive few messages like this:

GLI | ExtensionFunction::AddFunction -Unable to log function glVertexAttrib2dNV exceeded 500 num of wrapper functions
...
GLI | ExtensionFunction::AddFunction -Unable to log function wglSwapIntervalEXT exceeded 500 num of wrapper functionsAnd wglSwapIntervalEXT call actually isn't logged. Is there any way to increase this "num of wrapper functions"?

sqrt[-1]
02-07-2005, 01:27 PM
Yeah that is my fault. I thought 500 extenstion entry points would be enough for a long time (silly me) You can either recompile with more or wait for a minor 0.42 update. (in a few weeks)

yooyo
02-08-2005, 02:24 AM
@sqrt[-1]
I just made small plugin for GLI thats draws overlay graphs with number of glVertex calls, draw calls, num of transformed vertices and num rendered triangles. Something like NVPerfHUD.

There should be a lot of work to finish this plugin, and I don't have enogh time :( . Maybe community can help!?

Something like NVPerfHUD.

Would you like to send you a code? You can include it in GLI 0.42 release?

yooyo

sqrt[-1]
02-09-2005, 12:56 AM
Sure, send it though to my email.(you should find it in the readme)

I may not include it but I am curious how you coded it. (My main problem with someting like this is making it robust and handle all the weird states that can be enabled by an application)

sqrt[-1]
03-30-2005, 06:37 AM
Sorry for the thread bump...
All the issues found in this thread should be resolved in v0.42. It can be downloaded here:
http://home.swiftdsl.com.au/~radlegend/GLIntercept/
(and the nutty mirror soon)

Fixes:
dorbie: I added a lot of legacy function headers and updated some of the interfaces to accept the "old way" of doing things. (Half life origional should now run fine- I started learning with OGL 1.2 so I had no idea of these "old" ways.)

V-man: I added a "ping" plugin for people who have apps that do not regulary update. What this simply does is a windows refresh if a OpenGL swap buffers has not been called within a set amount of time. (This has to be enabled manually)

harsman and ATI users: The GLSL editor has been updated to work around some ATI bugs (Still does not work with sampler uniforms but you now have basic functionality)

zed : A function stats plugin has been added. When enabled, it will dump to the log on exit a listing of all the OpenGL function calls made and the counts.(sorted by count and by name)

OGL2.0 drivers with ASM shaders : I fixed a bug that was generating OpenGL errors when using ASM shaders with OGL2.0 drivers. (Ancient code bug from when I thought that OGL2.0 would roll the ASM shaders into core)

Bumped number of extension entry points from 500 to 2000 hopefully this will be enough for a long time.

Headers have been added for OGL2.0/FBO and others.

Things still waiting for the 0.5 release:
- OGL2.0 core shader interface. Currently the shader editor/logger only works with the ARB GLSL interface.
- Comment logging extension.
- Linux port.
- FBO/PBO/draw buffers support in advanced loggers : Image and frame buffer logging in the current version may be hit and miss if you use these extensions.

If you know of demos or apps that use OGL2.0 shader interface or FBO/PBO, send me a link as I need testing applications.

zed
03-30-2005, 10:30 AM
zed : A function stats plugin has been added. When enabled, it will dump to the log on exit a listing of all the OpenGL function calls made and the counts.(sorted by count and by name)hah, sweet i was actually thinking about updating my logging stuff last night too include all the glsl stuff, this will be a nice benchmark to check if the gl figures match up (to see where ive forgotten something in my code).
another useful function is to actually log the average number of calls per frame, ie after all initiation. very handy for optimization, eg ive found the most common gl call i make is glTexCoordPointer

zed
03-31-2005, 12:12 AM
i noticed a couple of differences between glintercept and my logger,
i assume most are from glIntercept calling the various get commands internally

glGetIntegerv // im logging less
glGetFloatv // im logging less
glBlendFunc // im logging heaps more ?
glGetBooleanv // im logging less
glGetQueryiv // im not using (except when i setup the extension ptr) but gliLog reports glGetQueryiv ... 1
glGetError // im logging less
glGetString // im logging less

sqrt[-1]
03-31-2005, 01:49 AM
I don't think the logger has the ability to log the internal calls I make.

The only thing I can think of is perhap you are making these calls without a context? (The plugin will count calls made out-side of a context) Or perhaps these calls are occuring behind your back if you use a loading library to load extensions? (no idea what is happening with glBlendFunc however)

As an experiment, enable the text logger then search for that glGetQueryiv call in the output log..

Pardon me for being a bit arrogant and assuming a bug in your code :) - I get a lot of bug reports that are false.
(If possible, give me a link to your app and I'll check it out)

zed
03-31-2005, 09:17 AM
sorry yes it was a bug in my code. i was going
create opengl bogus context
query various opengl info (hence all the glGet.. stuff)
destroy it
zero my logger
create the real window
run app

ill look into whats happening with the glBlendFunc cause there really is a big difference between the two figures mines about 5x as large (all the other 70 or so glcalls telly exactly between the two call loggers)