oglplus
oglplus copied to clipboard
matus-chochlik
Use ARB_debug_output instead of glGetError()?
Hello,
glGetError is great, but sometimes it doesn't give you enough information on what has gone wrong, only that it has gone wrong.
I was wondering if a new feature could be added so that if the context is created as a debug context, and the extension exists, use ARB_debug_output (or AMD_debug_output) instead of glGetError for error diagnostics. The call stack will follow to the exact piece of code that fails, and you could also possible get exceptions on bad performance code as well as error code.
http://www.opengl.org/registry/specs/ARB/debug_output.txt http://www.opengl.org/registry/specs/AMD/debug_output.txt
Something like this already is on the "TODO list", but I have to thing it through. There already is a wrapper for the ARB_debug_output extensions in OGLplus and it is used in the GLX "example-harness" to print info/warning/error messages to stderr, so in the meantime if you want you can use that. You just define a callback function that gets called whenever ARB_debug_output has something to say and if I'm not terribly mistaken you can also throw an exception from the callback if you want.
Ok, thanks. That'll do for me for now :-)
Which brings me to my second question. Is there a way to disable glGetError error checking so that it never calls glGetError?
Ah, yes, You need to define two PP macros: #define OGLPLUS_CHECK(X) glGetError(); #defne OGLPLUS_VERIFY(X) glGetError();
.. to call GetError without throwing, or ...
#define OGLPLUS_CHECK(X) #defne OGLPLUS_VERIFY(X)
to do nothing at all. You need to define them before including OGLplus.
When I try to build with OGLPLUS_USE_GLEW defined, ARB_debug_output.hpp seems to lack the glew.h. I mean I get errors like: ext/ARB_debug_output.hpp:101:1: error: ‘GLEW_ARB_debug_output’ was not declared in this scope
The line where the error happens: OGLPLUS_EXTENSION_CLASS(ARB, debug_output) Which becomes (from a macro in extension.hpp): (GL_ARB_debug_output) || (GLEW_ARB_debug_output) But I can't find glew.h to be included from any of the headers in ARB_debug_output.hpp, and well nor can g++ find it...
Strange, does this happen with the examples (I've just checked and I get no such error here) or with your application ? If it is your app. do you #include <oglplus/gl.hpp> (after defining OGLPLUS_USE_GLEW 1) ?
It happens when I try to build the examples. I get something like this:
Scanning dependencies of target oglplus_example_harness [ 1%] Building CXX object example/oglplus/CMakeFiles/oglplus_example_harness.dir/glx_main.cpp.o In file included from /home/tomius/Downloads/oglplus/example/oglplus/glx_main.cpp:30:0: /home/tomius/Downloads/oglplus/include/oglplus/ext/ARB_debug_output.hpp: In constructor ‘oglplus::ARB_debug_output::ARB_debug_output(bool)’: /home/tomius/Downloads/oglplus/include/oglplus/ext/ARB_debug_output.hpp:101:1: error: ‘GLEW_ARB_debug_output’ was not declared in this scope /home/tomius/Downloads/oglplus/include/oglplus/ext/ARB_debug_output.hpp: In static member function ‘static bool oglplus::ARB_debug_output::Available()’: /home/tomius/Downloads/oglplus/include/oglplus/ext/ARB_debug_output.hpp:101:1: error: ‘GLEW_ARB_debug_output’ was not declared in this scope /home/tomius/Downloads/oglplus/include/oglplus/ext/ARB_debug_output.hpp:101:1: warning: control reaches end of non-void function [-Wreturn-type] make[2]: *** [example/oglplus/CMakeFiles/oglplus_example_harness.dir/glx_main.cpp.o] Error 1 make[1]: *** [example/oglplus/CMakeFiles/oglplus_example_harness.dir/all] Error 2 make: *** [all] Error 2
What version of GLEW are you using.
b.t.w. doing the following in oglplus/extension.hpp should remove the error (I'll have to investigate why it is doing this):
42:- (GL_ ## VENDOR ## _ ## EXTENSION == GL_TRUE) ||
43:- (GLEW_ ## VENDOR ## _ ## EXTENSION == GL_TRUE) \
42:+ (GL_ ## VENDOR ## _ ## EXTENSION == GL_TRUE) \
I use GLEW 1.10.0 (the newest). If I include "GL/glew.h" to a program GLEW_ARB_debug_output is defined as true.
With removing the GLEW_ query, I don't get this error anymore.
There also might be another problem, namely that OGLPLUS_USE_GLCOREARB_H or OGLPLUS_USE_GL3_H are defined as a nonzero integer (for example in oglplus/site_config.hpp generated by cmake) if this is the case then these options take a precedence before OGLPLUS_USE_GLEW
Well I tried to build with these cmake options: set(OGLPLUS_USE_GLCOREARB_H 0) set(OGLPLUS_USE_GL3_H 0) set(OGLPLUS_USE_GLEW 1) set(OGLPLUS_USE_GL3W 0)
It is really likely that I'm doing something wrong, but there's another error that blocks me from building oglplus (it's not Glew only, it happens if I use either of the 4 extension loaders).
The problem is that I get undefined references to glProgramUniform* (The make terminates after 1i, and Matrix4fv). But my hardware does support GL_ARB_separate_shader_objects, and a simple program like this runs without error. int main() { sf::Window window(sf::VideoMode(640, 480), "Dummy Debug Window"); assert(glewInit() == GLEW_OK); glProgramUniform1i(0, 0, 0); glProgramUniformMatrix4fv(0, 0, 0, false, NULL);
return 0;
}
Here's the full error message I get:
Linking CXX executable 022_volumetric_light
CMakeFiles/022_volumetric_light.dir/022_volumetric_light.cpp.o: In function oglplus::aux::ProgramUniformSetters::_fns_t(std::integral_constant<unsigned long, 1ul>, int const*, ...)': 022_volumetric_light.cpp:(.text._ZN7oglplus3aux21ProgramUniformSetters6_fns_tESt17integral_constantImLm1EEPKiz[_ZN7oglplus3aux21ProgramUniformSetters6_fns_tESt17integral_constantImLm1EEPKiz]+0xcb): undefined reference toglProgramUniform1i'
CMakeFiles/022_volumetric_light.dir/022_volumetric_light.cpp.o: In function oglplus::aux::ProgramUniformMatrixSetters::_fns_v(std::integral_constant<unsigned long, 4ul>, std::integral_constant<unsigned long, 4ul>, float const*, ...)': 022_volumetric_light.cpp:(.text._ZN7oglplus3aux27ProgramUniformMatrixSetters6_fns_vESt17integral_constantImLm4EES3_PKfz[_ZN7oglplus3aux27ProgramUniformMatrixSetters6_fns_vESt17integral_constantImLm4EES3_PKfz]+0xcb): undefined reference toglProgramUniformMatrix4fv'
collect2: error: ld returned 1 exit status
make[2]: *** [example/oglplus/022_volumetric_light] Error 1
make[1]: *** [example/oglplus/CMakeFiles/022_volumetric_light.dir/all] Error 2
make: *** [all] Error 2
Could you please do 'make VERBOSE=true ...' and post here the output for one of the examples where the build is failing ?
I only get more documentation error :( Like this: http://pastebin.com/6MGtYbW0 (the error is at the end)
Hmm .. try re-running configure: ./configure.{py,sh} --from-scratch --no-docs --use-glew
also you can get rid of rebuilding the textures by downloading a packaged release and copying the _prebuilt directory to whereever you have cloned oglplus (into the root dir of the oglplus repository clone)
http://pastebin.com/b7cymtpY
Building the textures doesn't take much, just a few seconds it's ok.
Btw It probably has something to do with the updates in the extension loaders. I tried to find a previous version that works, to see when did it go wrong, but I get this undefined reference to glProgramUniform* with like every commit back until 5 of June (I get another error for commits older than that :( ) . But I've definitely had a successful build around 20 of June. I'm not quite sure how it was back then, but I think I only had the libglew-dev avaliable (is 1.8 I guess) back then. I defenitely remember that after I downloaded glcorearb I couldn't build it anymore without having force to use glew. And now after I updated glew I get the same error if I use glew, or glcorearb, or gl3w (which I recently downloaded too).
OK, thanks.
Where is your libGLEW.so located (one of the platform standard dirs or a custom location) ? It might be something that I fscked up during the changes to the build system, but I've been getting errors like this when I installed a new version of GLEW to /opt in addition to a standard installation and the two got messed up.
Another thing (which to me however happened only on Windows/MinGW) might be the order of libraries passed to g++ so you could try reordering them for example:
cd /home/tomius/Downloads/temp/oglplus/_build/example/standalone && /usr/bin/c++ CMakeFiles/001_program_resources.dir/001_program_resources.cpp.o -o 001_program_resources -rdynamic -lGLEW -lGL -lglut -lXmu -lXi
Glew is installed, not in a custom dir. And for g++, on linux, I believe that the order of the linking doesn't matter.
Some code:
tomius@Tomius-pc ~ $ sudo find / -name libGLEW.so [sudo] password for tomius: /usr/lib64/libGLEW.so
tomius@Tomius-pc ~ $ cd /home/tomius/Downloads/temp/oglplus/_build/example/standalone &&
/usr/bin/c++ CMakeFiles/001_program_resources.dir/001_program_resources.cpp.o -o 001_program_resources -rdynamic -lGLEW -lGL -lglut -lXmu -lXi CMakeFiles/001_program_resources.dir/001_program_resources.cpp.o: In function
oglplus::ProgramResource::QueryParams(unsigned int, int, int*, int*) const': 001_program_resources.cpp:(.text._ZNK7oglplus15ProgramResource11QueryParamsEjiPiS1_[_ZNK7oglplus15ProgramResource11QueryParamsEjiPiS1_]+0x89): undefined reference to__glewGetProgramResourceiv' CMakeFiles/001_program_resources.dir/001_program_resources.cpp.o: In functionoglplus::ProgramResource::ProgramResource(oglplus::aux::ProgramInterfaceContext&, unsigned int)': 001_program_resources.cpp:(.text._ZN7oglplus15ProgramResourceC2ERNS_3aux23ProgramInterfaceContextEj[_ZN7oglplus15ProgramResourceC5ERNS_3aux23ProgramInterfaceContextEj]+0x11c): undefined reference to__glewGetProgramResourceName' CMakeFiles/001_program_resources.dir/001_program_resources.cpp.o: In functionoglplus::ProgramOps::ActiveResourceContext(oglplus::enums::ProgramInterface) const': 001_program_resources.cpp:(.text._ZNK7oglplus10ProgramOps21ActiveResourceContextENS_5enums16ProgramInterfaceE[_ZNK7oglplus10ProgramOps21ActiveResourceContextENS_5enums16ProgramInterfaceE]+0x9b): undefined reference to__glewGetProgramInterfaceiv' CMakeFiles/001_program_resources.dir/001_program_resources.cpp.o: In functionoglplus::ProgramOps::ActiveResources(oglplus::enums::ProgramInterface) const': 001_program_resources.cpp:(.text._ZNK7oglplus10ProgramOps15ActiveResourcesENS_5enums16ProgramInterfaceE[_ZNK7oglplus10ProgramOps15ActiveResourcesENS_5enums16ProgramInterfaceE]+0x9c): undefined reference to__glewGetProgramInterfaceiv' collect2: error: ld returned 1 exit status
hmm, and does nm -D /path/to/lib/libGLEW.so.1.10.0 | grep -e 'ProgramResource' print anything ?
Sry was afk.
tomius@Tomius-pc ~ $ nm -D /usr/lib64/libGLEW.so.1.10.0 | grep -e 'ProgramResource' 000000000028b7c8 B __glewGetProgramResourceIndex 000000000028b7a8 B __glewGetProgramResourceiv 000000000028b7c0 B __glewGetProgramResourceLocation 000000000028b7b8 B __glewGetProgramResourceLocationIndex 000000000028b7b0 B __glewGetProgramResourceName
ok, color me confused. no luck googling anything useful either :-P I'll have to install GLEW 1.10 myself and try it out.
I've tried doing a similar thing; removed the #include <GL/glcorearb.h> and #include <GL3/gl3.h> and placed an #error in all the PP branches in oglplus/gl.hpp to make sure that GLEW is used. Ran ./configure.py --from-scratch --no-docs --use-glew and everything builds as it should.
But I can confirm that when GLX is being used then the GLEW initialization somehow fails even if glewInit definitely is being called and it returns GLEW_OK. When I add --use-glut to configure then everythin compiles and most examples runs without any problems (some still fail with the 'function called throught invalid pointer' error).
I'll have a look at this.
I tried it too, and with glut, every example runs fine, that my hardware can run. However I still get errors at 001_program_resources so I have to build with make -i.
I've made some changes and now the GLX/GLEW combination is working at least at the one machine I have access right now. Could you pull the latest changes from develop and try if that fixes the problems you are having ?
The config said it couldn't detect GL version and assumes 3.0. Also it acts like -lGL was missing. I get a lot of error like this: /usr/bin/ld: liboglplus_example_harness.a(glx_main.cpp.o): undefined reference to symbol 'glXMakeCurrent' /usr/bin/ld: note: 'glXMakeCurrent' is defined in DSO /usr/lib/nvidia-313-updates/libGL.so.1 so try adding it to the linker command line /usr/lib/nvidia-313-updates/libGL.so.1: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status /usr/bin/ld: liboglplus_example_harness.a(glx_main.cpp.o): undefined reference to symbol 'glXMakeCurrent' /usr/bin/ld: note: 'glXMakeCurrent' is defined in DSO /usr/lib/nvidia-313-updates/libGL.so.1 so try adding it to the linker command line /usr/lib/nvidia-313-updates/libGL.so.1: could not read symbols: Invalid operation
Strange in the meantime I've tested the same config on two other machines and on both it works. Try replacing: set(OGLPLUS_GL_LIBS ${GLEW_LIBRARIES})
with
set(OGLPLUS_GL_LIBS ${GLEW_LIBRARIES} ${OPENGL_LIBRARIES})
on line 134 in ./CMakelists.txt
Uff, finally :) I was starting to run out of ideas :P Thanks for the feedback!