Re: [osg-users] OpenGL capture/logging in OSG
Hi Paul I'm also interested in the ogldump route, specifically because of the automated wrapper generation. cheers -- mew On Mon, Dec 14, 2009 at 2:06 PM, Paul Martz pma...@skew-matrix.com wrote: ... I don't know if this might help, but Don Burns wrote a parser of the gl.h to automatically produce a wrapper library that allowed you that calls GL for you, and you just link to the Don's OglDump library. For more details: http://www.andesengineering.com/OglDump/ogldump.html It's written for unix, using lex/yacc, so one would need to do some more work to get it working under Windows, but it might give one a leg up. Thanks for the pointer. If I'm already going to look at the Linux-centric BuGLe, then I could give this a shot too. (Lex and yacc, wow, I used to know how to use those back in 1986...) -Paul -- Mike Weiblen -- Black Hawk, Colorado USA -- http://mew.cx/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL capture/logging in OSG
Hi Paul, I'm still open to suggestions on the make up of what your are looking, but I don't yet think you have the right design combination to avoid pitfalls of it's own. Though discussion perhaps we can arrive at a better solution, be it OSG intrusive or done externally. On Fri, Dec 11, 2009 at 4:46 PM, Paul Martz pma...@skew-matrix.com wrote: I think I've already addressed the performance and maintenance concerns in my first post. To recap, by default, OpenGL calls would go directly into OpenGL. As for maintenance issues, I'd argue that we already have them, and a system like I'm proposing would actually make it easier to add new OpenGL features and extensions, as well as add them in a unified and consistent way. Having a single class is not extensible by end users - something which is essential for authors of external NodeKits. Using an optional compile between macro's/inline functions and the modified versions to avoid performance degradation will lead to binary in-compatibility between the code with diagnostics and one without. If one did keep binary compatibility then use need to use a template method design pattern with an extra if (callback) callback(data..) else glFunction(data...) which while binary compatible will introduce a performance hit. -- I don't know if this might help, but Don Burns wrote a parser of the gl.h to automatically produce a wrapper library that allowed you that calls GL for you, and you just link to the Don's OglDump library. For more details: http://www.andesengineering.com/OglDump/ogldump.html It's written for unix, using lex/yacc, so one would need to do some more work to get it working under Windows, but it might give one a leg up. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL capture/logging in OSG
Hi Robert -- Robert Osfield wrote: Having a single class is not extensible by end users - something which is essential for authors of external NodeKits. It's not a requirement that external source use the new interface for calling OpenGL. If they don't use it, code will still function properly, but there will be no logging or other instrumentation of their code's OpenGL calls. This is analogous to how OSG's plugin documentation feature works. External code that doesn't use the feature is still able to load files, but doing an osgconv --format for that plugin displays no information. But I don't think anyone would say that the plugin documentation feature is not extensible. This new capability should be very extensible in that, if you needed to log calls into a new OpenGL feature or extension not currently in OSG's OpenGL class, it would be as easy as dropping in the enum defs and function signatures and rebuilding OSG. Using an optional compile between macro's/inline functions and the modified versions to avoid performance degradation will lead to binary in-compatibility between the code with diagnostics and one without. Binary compatibility is not an issue. Developers will never turn on instrumentation in production code. It'll only be used during development, where binary compatibility isn't needed. I don't know if this might help, but Don Burns wrote a parser of the gl.h to automatically produce a wrapper library that allowed you that calls GL for you, and you just link to the Don's OglDump library. For more details: http://www.andesengineering.com/OglDump/ogldump.html It's written for unix, using lex/yacc, so one would need to do some more work to get it working under Windows, but it might give one a leg up. Thanks for the pointer. If I'm already going to look at the Linux-centric BuGLe, then I could give this a shot too. (Lex and yacc, wow, I used to know how to use those back in 1986...) -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL capture/logging in OSG
Another program worth for considering would be Bugle (http://www.opengl.org/sdk/tools/BuGLe/). Just my 2 cents. -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL capture/logging in OSG
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 pma...@skew-matrix.com 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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL capture/logging in OSG
Responding to all three posts at once... Chris 'Xenon' Hanson wrote: I think I've used glIntercept before and dfound it pretty useful. What was the motivation in not building on it? Lack of support for multiple threads, and no obvious way to add that support, was one reason for abandoning it. Also, when I attempted to use GLIntercept with (single threaded) OSG, I encountered problems as described recently in the discussion thread GLIntercept and OSG 2.8.2 on this list, as if the device driver were launching its own internal thread that called back into itself. As for BuGLe, there's an obvious bias towards Linux. Also a heavy third party dependency chain (my scheme would have no dependencies other than OSG plugins for optionally writing images). BuGLe also has its own debugging interface, whereas my system would allow the user to set breakpoints and collect backtraces using the debugger they are already familiar with, a much better solution IMO. I think I've already addressed the performance and maintenance concerns in my first post. To recap, by default, OpenGL calls would go directly into OpenGL. As for maintenance issues, I'd argue that we already have them, and a system like I'm proposing would actually make it easier to add new OpenGL features and extensions, as well as add them in a unified and consistent way. Anyhow, I just wanted to throw it out for consideration in case others were interested. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL capture/logging in OSG
On 12/11/2009 9:46 AM, Paul Martz wrote: Lack of support for multiple threads, and no obvious way to add that support, was one reason for abandoning it. Also, when I attempted to use GLIntercept with (single threaded) OSG, I encountered problems as described recently in the discussion thread GLIntercept and OSG 2.8.2 on this list, as if the device driver were launching its own internal thread that called back into itself. Makes sense. I always look for the widest opportunity to share technology with other groups, so I wondered what glintercept's poison was that made it unsuitable. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenGL capture/logging in OSG
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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
