Re: [osg-users] nVidia 64-bit quadro drivers and large number of primitives (2.8.3)
Hi Andrew, On Fri, Dec 24, 2010 at 3:52 PM, Andrew Cunningham > When trying to fix this, I modified OSG and "chunked" up the calls to > glDrawElements inside PrimitiveSet.cpp to be GL_MAX_ELEMENTS_INDICES in > size. Anything wrong with this approach? It depends upon how you implemented it. You certainly wouldn't want to do a glGet for GL_MAX_ELEMENTS_INDICES on every frame, let along call to do a single primitive set. It's also questionable whether we should be doing extra checks on size to catch cases when users are passing data to the OSG that can't be rendered with OpenGL. The OSG isn't your nanny, it assumes that you know what scene graph is required to render properly on your system and doing so doesn't burden the OSG with extra checks that are only required for scene graphs that have inappropriate sizes. The best approach for any checking this this is to do it in a data preparation and optimization when you create the data or load it into memory. >This would mean the OSG user need not be concerned about whether they are >using 'too many' vertices/primitives. But it would mean that everyone pays in performance for the benefit of a tiny number of developers not building scene graphs appropriate for there target hardware. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] nVidia 64-bit quadro drivers and large number of primitives (2.8.3)
robertosfield wrote: > Hi Andrew, > > I wouldn't recommend creating a single osg::Geometry with millions of > vertices/primitives, while in theory it should work, even if it does > it's likely to perform poorly as the GL driver won't be able to just > render the data directly - it'll need to stream it in chunks. > Hi Robert, When trying to fix this, I modified OSG and "chunked" up the calls to glDrawElements inside PrimitiveSet.cpp to be GL_MAX_ELEMENTS_INDICES in size. Anything wrong with this approach? This would mean the OSG user need not be concerned about whether they are using 'too many' vertices/primitives. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35157#35157 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] nVidia 64-bit quadro drivers and large number of primitives (2.8.3)
Hi All, I did some testing with gDebugger (now free!) and the its support for "nVidia Expert" - totally clean, no errors. No breakpoints. And when running under gDebugger there were no problems What did fix it was going to the nVidia Control Panel and changing the global application settings to "3D App - Visual Simulation". Go figure. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35144#35144 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] nVidia 64-bit quadro drivers and large number of primitives (2.8.3)
On 12/23/2010 12:57 PM, Andrew Cunningham wrote:
Once the osg scene graph is created, and the render phase begins. I see the border of my screen
"flash" black twice and then my application is in "la-la" land, with a blank 3D
window and needs to be killed. The app is using about 2G of memory but I have 9G free.
Sounds like a possible driver bug. Are you able to try different drivers or
different graphics cards? Try a GeForce or an ATI for example. Or try a 32-bit
system with a 32-bit build. If you can isolate it to a single graphics device
and set of drivers, NVIDIA might be able to produce a fix for you.
("La la land", that's a Happy Days reference, right? Heyy...)
-Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] nVidia 64-bit quadro drivers and large number of primitives (2.8.3)
Hi Andrew, I wouldn't recommend creating a single osg::Geometry with millions of vertices/primitives, while in theory it should work, even if it does it's likely to perform poorly as the GL driver won't be able to just render the data directly - it'll need to stream it in chunks. To get big datasets working efficiently it's best to break them up into chunks of tens of thousands of points and to use VBO's. This way the OpenGL data can pass the data in blocks of a size that are much more amenable to being downloaded directly to the graphics hardware. The src/osgPlugins/3dc plugin can handle tens of millions of points with decent performance, and achieve this by doing the chunking of the data I suggest above, so have a look at it's source for inspiration. Robert. On Thu, Dec 23, 2010 at 7:57 PM, Andrew Cunningham wrote: > Hi, > I have a Quadro FX 1700 with the latest 64-bit Nvidia drivers on Windows > XP/64. My app is a 64-bit Windows application. > > For testing I am creating a single osg::geometry with probably about 3.2 > million QUAD primitives , using > quadPrims_=new osg::DrawElementsUInt(osg::PrimitiveSet::QUADS); > > I am not using VBO's. > > Once the osg scene graph is created, and the render phase begins. I see the > border of my screen "flash" black twice and then my application is in "la-la" > land, with a blank 3D window and needs to be killed. The app is using about > 2G of memory but I have 9G free. > > > More info... > - osg does not report any errors > > - if I turn off the nVidia driver and switch to the default "software" OpenGL > driver, the geometry renders fine. > > - If I take a geometry of a similar size or even much bigger, but break it up > into multiple geometries so that each DrawElementsUInt is "smaller" there are > no problems. > > I am not aware of any specific limitations on glDrawElements that says the > number of elements must be < "some number". The reference guide says there > may be performance problems with numbers > GL_MAX_ELEMENTS_VERTICES/INDICES > but it is not a hard limit. > > Any one experienced similar problems? > > Andrew > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=35136#35136 > > > > > > ___ > 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
[osg-users] nVidia 64-bit quadro drivers and large number of primitives (2.8.3)
Hi, I have a Quadro FX 1700 with the latest 64-bit Nvidia drivers on Windows XP/64. My app is a 64-bit Windows application. For testing I am creating a single osg::geometry with probably about 3.2 million QUAD primitives , using quadPrims_=new osg::DrawElementsUInt(osg::PrimitiveSet::QUADS); I am not using VBO's. Once the osg scene graph is created, and the render phase begins. I see the border of my screen "flash" black twice and then my application is in "la-la" land, with a blank 3D window and needs to be killed. The app is using about 2G of memory but I have 9G free. More info... - osg does not report any errors - if I turn off the nVidia driver and switch to the default "software" OpenGL driver, the geometry renders fine. - If I take a geometry of a similar size or even much bigger, but break it up into multiple geometries so that each DrawElementsUInt is "smaller" there are no problems. I am not aware of any specific limitations on glDrawElements that says the number of elements must be < "some number". The reference guide says there may be performance problems with numbers > GL_MAX_ELEMENTS_VERTICES/INDICES but it is not a hard limit. Any one experienced similar problems? Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35136#35136 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
