How expensive are OpenGL error checks and would it be overly detrimental to performance if I did it on a per frame basis?
Why not remove/add the test and see what it does in FPS 
i have MANY glGetError in my code, and i cant see any speed difference. basically the glgeterror code should be something like
int glGetError() {
int retval = ErrorCode;
ErrorCode = 0;
return retval;
}
so the cost cannot be much… the errorcode is set by the function that generated the error independend if you read it or not.
Originally posted by Mazy:
so the cost cannot be much… the errorcode is set by the function that generated the error independend if you read it or not.
you’re right when you say that your error checking code wont affect much the performance of the program.
mrShoe:
anyway, you should avoid the error checking during on a per frame basis because calling too many functions makes your processor spend too much time with allocation/dealloction of memory resources for the functions, wich could be important when you have a cpu intensive program running. this problem can be solved partially if you define your function with the ‘inline’ keyword.
anyway, i suggest that you only use error checking for the initialazation of your program.
[This message has been edited by jcabeleira (edited 07-23-2003).]
Huh ? Current processors can call millions, if not billions of functions per second. The cost of calling glGetError once per frame, 10 times per frame, or 1000 times per frame will likely to be negligible.
Y.
it’s wrong, think about it:
- first, is it really necessary?
- second, if you call too many functions on a cpu intensive program it’ll make a difference on the performance because the processor will be spending it’s time calling 200(for example) error checking functions when he could be processing graphics, even with current processors.
mrShoe:
i dont’t really know how your program works but in my oppinion error checking during the rendering is just avoidable. if you want to do a cpu intensive program then i suggest you release the cpu from the error checking task otherwise you can just leave-it because it won’t make a difference.
During debug i call glgetError almost after each gl-functioncall, and most of my programs are GPU / transfer speed bound so i dont get any speedup when i remove them. I bet its atleast 1000 of them per frame. But if youre cpu-bound then all optimizations might help.
There are two kinds of errors: RUNTIME errors, and USAGE errors.
During debug, you should assert that glGetError() return 0 after every OpenGL call. This weeds out all the USAGE errors.
During release, you presumably already debugged your program, so you only need to call glGetError() after calling functions which are defined to fail for RUNTIME reasons, rather than USAGE reasons. That’s… uh… none of them, according to the spec 
Although texture upload can fail, so you should probably check there. When you upload textures, the cost of the upload is likely to dominate the cost of checking by a factor of 100,000 or so.
Then the question is: what will you do when you find an error?
i absolutelly agree with jwatte. it’s just useless to call glGetError after calling, for example, glBindTexture because the error will come for sure from an initialization problem. OpenGL just doesn’t fails like that…
Originally posted by jwatte:
Then the question is: what will you do when you find an error?
Display a blue screen with some non-sensical driver based error message that the user can jump onto an Advanced GL coding forum and ask about…
Or was that a rhetorical question…
knackered, I think you should go back to that thread, and post your conclusions about what was slowing it down.
Matt said it’s trivial, you claimed it very slow. Why so? How many asm instructions did you step over inside the function?
I normally use a macro, for all gl functions, that automatically calls glError, and brings a message box up. I never noticed any degradation in speed.
Nutty
I guess that there is a risk that glGetError will cause major slow downs on a user`s machine.
Better have them cancelled out in the release build.
Still, it`s surprising what happened to knackered.
Woah there, don’t shoot the messenger Nutty.
I’ve got vague memories of it - I remember one thing for sure, not calling glGetError gave me a massive performance boost. How that can be explained is anybodies business.
vtune can be finicky about where it says your time is spent. If there is a function after glGetError in the DLL that it doesn’t have a starting address and name for, then it will assume that code is a part of the function glGetError. vtune once showed me that 60% of my CPU was spent in the UI button constructor, even though what I was doing had nothing to do with the UI buttons.
Anyway, thanks for all the replies. The program isnt anywhere near finished atm, as in it doesnt do all that much, so leaving in the error checking would probably cost alot, but if the program was doing something other than checking for errors, it might not cost much. Ill probably leave the error checking in for the debug build, and take it out for the release build, or most of it at least.