(Cross-posting to the osgWorks Google Group.)
osgWorks r474 now has a singleton instance that allows apps to access
GL_RENDERER and other values without a current context. To use this tool, do
something like the following:
osgwTools::Capabilities* caps =
osgwTools::CapabilitiesSingleton::instance()->getCaps();
Then you can do anything you would normally do with the Capabilities object,
such as:
// Dump out all the queried values:
caps->dump( osg::notify( osg::ALWAYS ) );
// or just get a copy of the GL_RENDERER string:
const std::string rendererStr = caps->_glRenderer;
Calling dump() produces output like this:
osgWorks version 2.0.3 (20003).
OSG version: 3.1.4
Queryable strings ----------------------------------------
GL_VERSION: 3.3.0
GL_VENDOR: NVIDIA Corporation
GL_RENDERER: GeForce 9800M GT/PCIe/SSE2
GL_SHADING_LANGUAGE_VERSION: 3.30 NVIDIA via Cg compiler
Texture implementation constants -------------------------
GL_MAX_TEXTURE_SIZE: 8192
GL_MAX_3D_TEXTURE_SIZE: 2048
GL_MAX_CUBE_MAP_TEXTURE_SIZE: 8192
GL_MAX_TEXTURE_UNITS: 4
Shader implementation constants --------------------------
GL_MAX_TEXTURE_IMAGE_UNITS: 32
GL_MAX_TEXTURE_COORDS: 8
GL_MAX_VERTEX_ATTRIBS: 16
GL_DRAW_BUFFERS: 8
I'm not exactly sure how OSG's pbuffer creation works in the case of
heterogeneous GPUs. I imagine there is a "primary" GPU that handles the context
creation. To use osgWorks to get per-GPU capabilities, you would need to create
a separate instance of an osgwTools::Capabilities object while a context is
current on each separate GPU. This can probably be done with a Camera draw callback.
-Paul
On 1/15/2013 10:16 AM, Paul Martz wrote:
Chris, you're right about the heterogeneous case.
Current svn trunk HEAD of the osgWorks project has a couple tools that might
help.
There is a struct osgwTools::Capabilities that your app can invoke while any
context is current (as in a Camera pre-draw callback). It obtains the
GL_RENDERER string plus other strings and GL implementation dependent constants.
It has a dump(std::ostream&) method, which your app can invoke to display the
queried values.
There is also a standalone application called osgwcaps, which simply creates a
pbuffer context, makes it current, creates a Capabilities struct, and dumps the
values to osg::ALWAYS.
Chris, I agree it would be nice to have this someplace instantly accessible. I
might be able to add a static that would query these values at DLL load time.
I hope this helps.
-Paul
On 1/15/2013 8:17 AM, Chris Hanson wrote:
I've been in this situation before too, and it would be very handy to have the
GL_RENDERER and other identifying strings stored in OSG for the user code to
query. Since many people don't know you have to have the context valid, and
others don't know where/when OS has a valid context bound, it would be useful.
Potentially, this information could be per-window-specific, couldn't it?
Multiple heterogenous display cards on one machine could return different
results for different contexts.
On Tue, Jan 15, 2013 at 4:32 AM, Alistair Baxter <[email protected]
<mailto:[email protected]>> wrote:
My solution thus far has been to call glGetString in the same function after
my call to osg::GL2Extensions::Get, since the OpenGL context appears to be
valid at that time - indeed the glGetString call is made internally by the
GLExtensions stuff at that time.____
__ __
It just seems like the renderer string should be exposed by the extensions
object and it’s not.____
__ __
*From:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]
<mailto:[email protected]>] *On Behalf Of *Gianluca
Natale
*Sent:* 15 January 2013 10:54
*To:* OpenSceneGraph Users
*Subject:* [osg-users] R: GL_RENDERER string____
__ __
Out of OSG/Qt, I think you should:____
__1)__Create a very simple rendering context (associated to the window
created by your application);____
__2)__Make that rendering context as the current one;____
__3)__Call glGetString(GL_RENDERER, …);____
__ __
Steps 1 and 2 are required, since all gl calls need a current rendering
context to work with.____
About steps 1 and 2, you should look at how OSG create the rendering
context.____
__ __
*Da:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]] *Per conto di *Alistair
Baxter
*Inviato:* martedì 15 gennaio 2013 10:47
*A:* [email protected]
<mailto:[email protected]>
*Oggetto:* [osg-users] GL_RENDERER string____
__ __
I’m wanting to get the GL_RENDERER string out of my OpenSceneGraph / Qt
application for debug purposes, and potentially for showing to users for
technical support purposes.____
__ __
I can get the likes of GL and GLSL version from the osg::GL2Extensions
object, and I can see the renderer string being queries in the source code,
but I’m having difficulty figuring out how to get it out.____
_______________________________________________
osg-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Chris 'Xenon' Hanson, omo sanza lettere. [email protected]
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL
• OpenGL ES 1 • OpenGL ES 2 • OpenCL
Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography •
Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android
@alphapixel <https://twitter.com/alphapixel> facebook.com/alphapixel
<http://facebook.com/alphapixel> (775) 623-PIXL [7495]
_______________________________________________
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
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
