Whenever I try to “Start Graphics Debugging” I get the following fatal error: “This application is attempting to use an OpenGL name which was not declared with the appropriate glGenXXX function. Nsight is not currently compatible with this legacy name usage.”. If someone could help me track down what is causing this issue and how I could fix it I would appreciate it. I tried googling for this error message but apparently no one else in the world has it because there are zero results.
I think this should not be too hard to track. If you follow the link provided by rafi there is a legacy note:
In OpenGL versions before 3.0, the user was allowed to ignore the generation step entirely. The user could just decide that “3” is a valid object name, and start using it like an object. The implementation would then have to accept that and create the object behind the scenes when you first start using it. In GL 3.0, this behavior was deprecated. In core GL 3.1 and above, this is no longer allowed. Regardless of the version of OpenGL, it is always good practice to use glGen* rather than making up your own object names.
Then lookout for OpenGL-Objects you use and check if you created them using their appropriate glGen* function or not e.g. you use the id directly instead of calling glGen* first which returns you an id for it.
Objects created with glGen* are: Buffers, Framebuffers, Programpipelines, Queries, Renderbuffers, Samplers, Textures, Transformfeedbacks and Vertexarrays.
How do you create your OpenGL-Context and which profile and version do you create?
I am using OpenGL 3.2 at the moment, there is unfortunately quite a bit of code in my project and I was hoping not to have to go through each file to try and find the code that contains the error by hand.
Is there a way to set the harshness of the profile, say like you might with warnings, to flag up the error earlier? I remember as well there being some GL macro that you may be able to use to detect errors at stages during OpenGL initialization but I don’t remember what it was, any ideas would be greatly appreciated!
Actually I have just managed to track down the problem. I was using a hard-coded value for a textureID when calling glBindTexture, I added a call to glGenTextures(1, &texId) before it, and then passed texId to glBindTexture and that solved the problem.
I added a glGetError call after the offending code (having temporarily reverted my fix) and the error code was just 0, so it hadn’t detected anything was wrong. I tried changing the profile to be CORE when I initialize OpenGL but that didn’t seem to make any difference.
You would hope you would be able to set OpenGL to a state where it can detect when an error like this occurs but I’m not sure how, if anyone knows I am sure that could be a very helpful tool to debug this problem in the future should it arise for someone else.
Here is my approach: I defined a macro GL_CHECK_ERRORS which evaluates in DEBUG-Build to a function call
which checks and prints current opengl-errors with the call to glError (see [url]http://www.opengl.org/sdk/docs/man/xhtml/glGetError.xml[/url] you should call it in a loop…) - I attach FILE and LINE macros for specific locations.
In RELEASE-Build it evaluates to an empty string and simply does nothing. I then add this macro after all opengl-calls I do in my program so when running the debug-build I get the exact location of the call when something fails. I also add a normal glErrors-check at the end of each frame in release-build so that I can also track if something is wrong in release.
Recently I added another error-detection mechanism: OpenGL Debug-Context. In debug-build I request a Debug-Context using GLFW and then enabling debug-messages. See [url]http://blog.nobel-joergensen.com/2013/02/17/debugging-opengl-part-2-using-gldebugmessagecallback/[/url] for how to use it. Your card and drivers need to support OpenGl 4.3 though.
This is most probably the cleanest way to do it because it spares you the work of inserting the glError-macro checks after every OpenGL-call. The downside is that you loose the specific location information so you need to “guess” a little bit.
Cool thank you for the links and information! I have something similar to the glCheckError pattern you describe but unfortunately that did not catch this problem.
I have been doing some Googling but haven’t found a conclusive answer for whether it is possible to set the Core profile and detect errors when deprecated functions or techniques are used (maybe with functions but not with the error mentioned at the start of this thread).
If I am able to get something to detect this specific problem I’ll make sure to update this thread.
As an aside, now it’s working for me, Nsight is fantastic! I will never try to debug graphical problems without it! :)
Well the problem is that you need to put this check after all of your opengl calls otherwise it would show up somewhere as every call could cause errors.
Sure it is possible to detect errors with Core-profile: you need to define it as debug-profile too and use the debug-messages i mentioned in the post before. A debug-message will be created always when you use a funciton which is deprecated. Thats how i found out that i have to use VAOs instead of enabling and disabling vertex attributes before every draw-call - saved a lot of opengl-calls.
I’m using GLFW to request a opengl-context, i tried to use win-native stuff but that sucked so bad and was so cumbersome that i switched to GLFW which gets it done in about 10 lines.
Yes Nsight is really great, i’m also using gDebugger sometimes and before i knew Nsight but having no debugging-tools for graphics programming is a real pain in the a**
Ah I see, yeah I am using WGL with GLEW, I only recently found out about GLFW so I might try and set that up instead, thanks. Ah right, I may just be missing the debug-profile, I’ll do some more digging otherwise I might move to GLFW, probably easier :P Thank you again for your help!
While explicitly generating names is the preferred approach for OpenGL object names, I’d like to mention that in the next release of Nsight this ‘compatibility naming’ will actually be supported.