Hi J-S i am working with NVidia GPU, and i have same behaviour. So there should be another problem than the busy wait. Of course can VSync give some problem in performance or at least we get a smaller FPS displayed. But here we have some strang behavior of our osgViewer (renderer). My there is a bug inside the synchronisation.
But what i guess is: When we are running under --SingleThreaded : bool GraphicsWindowWin32::realizeImplementation() wglMakeCurrent SwapBuffers all are called in the same thread. if we are working without singlethreaded option, then the realize get call in the "master" thread and in the others wgl based method call get called in a second thread. may the operating system (driver) understand, that there must be more than one thread in the "world" and starts an extra synchronisation which cause the CPU overload. /adrian 2009/2/2 Jean-Sébastien Guay <jean-sebastien.g...@cm-labs.com> > Hi Cory, > > I'll have to defer to others on the situation under Windows when doing >> remote desktop. My guess is that it's likely to be a driver issue. >> > > Well, using Remote Desktop adds a variable into the mix for sure, so > eliminating this and running the app locally would eliminate one possible > thing. > > About one core being pegged, some video drivers implement vsync as a busy > wait, which means that the CPU is not really pegged, it just looks like > that. If you were to actually run real code on that core, along with OSG, > you would see that that code would run at a normal speed because the vsync > busy wait would relinquish the CPU while it's waiting for the next frame to > start. > > So my guess is that your ATI drivers are doing this, and what you're seeing > is just the idle time between frames being counted as active time by Process > Explorer because it's implemented as a busy wait. Of course, I'm speculating > here, you'll have to run a real app (not just osgviewer) to see for > yourself. > > Note also that ATI's OpenGL drivers have never been the best... Though they > say they're getting better, they have a long way to go. So there might be > some of that here. > > Hope this helps, > > J-S > -- > ______________________________________________________ > Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ > http://whitestar02.webhop.org/ > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- ******************************************** Adrian Egli
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
