Hi Paul, My instinct would be to be not recommend trying to add some extra level of indirection in OpenGL calls to the OSG, from a maintenance and performance perspective. Considering most of us can get by without it it's sure note a cost that I ever want to push out to everyone. Cost of maintenance also means that other tasks go slower as they receive less time so the potential fallout isn't just localised to OpenGL call management.
In terms of centralization of extensions/GL calls, this is something I have deliberately avoided as it's not a extensible approach as you'd have a single class that everyone would have to extend to add their extension support into. 3rd party NodeKits that add their own extensions would either have to get them added into the core OSG is just roll their own as they do now. I would, however, be happy to see a more formalized system for extension setup, as the current distributed approach has let the styles of implementation diverge as a series of different developers have got their hands dirty contributing code. In terms of a GL capture I would personal go the route of a 3rd party tool like GLintercept, and parse the GL headers to capture function calls and add diagnostics. On the OSG side would could add an ability to pick a different GL library that than the standard one to make this diagnostics easier, but given we can control link paths to libs it's not too hard to substitute as is. Robert. On Fri, Dec 11, 2009 at 2:49 AM, Paul Martz <[email protected]> wrote: > Hi all -- > > I have some funding to capture OSG's OpenGL calls. This is required for > development, debugging, and performance analysis work that I am currently > contracted for. I have already ruled out updating GLIntercept for this > purpose. > > Purchasing gDEBugger is a possibility. However, the upfront cost is large, > and the lack of control in this closed-source tool is undesirable. Most of > my work is OSG-related, so I have little need for gDEBugger's general OpenGL > analysis capability. > > This brings me to the point of my post: adding OpenGL capture directly to > OSG. > > My idea so far is to take a private snapshot of OSG, then modify it so that > all OpenGL calls go through function wrappers (many do already) or a CPP > macro. By default, the call would go straight into OpenGL, but a developer > could enable instrumentation through CMake so that OSG captures OpenGL > command info before calling into OpenGL. This would record the call to a > log, allow breakpoints, record timing data, capture texture image data and > shader source to files, any number of things, really, but essentially the > capabilities found in GLIntercept. > > The capture would be thread safe and support multiple contexts. Support for > new OpenGL features and extensions would be trivial; the OpenGL wrapper code > would be automatically generated from gl.h or extension header files, so > just drop in the enum defs and function declarations and rebuild. > > Initially, my inclination was to do this on my own, basically make my own > private instrumented branch of OSG. But then I realized that there are other > benefits that this change could bring to OSG, and it might be worth folding > into the source. > > Consider how OSG currently calls into OpenGL. OSG might call OpenGL > directly, or load and call through a function pointer, or call into a > function wrapper that manages a function pointer. When OSG does call through > a function pointer or into a function wrapper, the code for doing this is > scattered in multiple classes, headers, and source files (e.g., > GL2Extensions, FrameBufferObject, etc). Adding OpenGL capture to OSG would > give us a chance to unify this code and make it consistent. Access to all > OpenGL commands would go through a single class, and done consistently > through a CPP macro or function wrapper. This would be a good code cleanup. > > Plus, I also thought there might be others besides myself that wanted to > capture OpenGL command streams. It's really quite a valuable development > tool. > > Because this might have value for many developers, I am posting here for > discussion. If the community is interested, I am willing to work with others > to satisfy requirements. If the community is not interested, I'll either do > my own private branch or purchase gDEBugger. > -- > Paul Martz > Skew Matrix Software LLC > _http://www.skew-matrix.com_ <http://www.skew-matrix.com/> > +1 303 859 9466 > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
