That reminds me - in my lab we've run into some issues where having hyperthreading enabled for high-throughput operations like heavy GPU work can have a negative performance impact. Not sure of the specifics, and I don't see why it would cause your time-delay slowdown, but perhaps some scheduling-related task interacts with hyperthreading.
Ryan On Thu, Jun 16, 2011 at 2:25 PM, Dardo D Kleiner - CONTRACTOR < [email protected]> wrote: > Try pinning the process to particular core(s) (e.g. via > pthread_setaffinity_np(3) or cpuset(7)). We have a particular piece of > hardware on which GL performance (in general, not necessarily gl_readpixels) > tanks when the Linux scheduler decides to place the process on core #7 (i.e. > the last core of a dual-socket, quad-core, non-HT machine). This behavior > observed on at least 7 identical machines. > > What fun that was to diagnose... > > - Dardo > > > On 6/16/11 1:57 PM, John Vidar Larring wrote: > >> Hi Robert, >> >> Thanks for your help. See comments inline below: >> >> Robert Osfield wrote: >> >>> >>> The OSG svn/trunk and recent 2.9.x dev series has support for setting >>> a texture pool size >>> that is able to limit the amount of texture memory used, you can set >>> this via the env var: >>> >>> set OSG_TEXTURE_POOL_SIZE=200000 >>> >>> When sets the size to 200 thousands bytes. Set it to different values >>> and study the reported available memory on the GPU. >>> >>> Whether reducing the amount of memory used on the GPU will have an >>> effect I can't say - it all depends upon what is actually the >>> bottleneck. >>> >> >> Unfortunately, our application is still not fully converted to OSG, so >> we're note able to take advantage of the OSG_TEXTURE_POOL_SIZE straight off >> the bat. But hopefully within this time next year we >> will. For the time being will have to live with a mix of old-school GL and >> OSG. >> >> In terms of possible causes of a stall you could check to see if there >>> are any processes on the client machine that are running periodically >>> - virus checkers etc. >>> >> >> Thanks, but already checked. We're running on linux and we've monitored >> all processes without finding any culprits here. >> >> Also check with NVidia. They might have an idea. >>> >> >> So far, no response from Nvidia so far. The osg-users list has by far >> given us the best clues/help/support, so kudos to the community!!! >> >> Best regards, >> John >> _______________________________________________ >> 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 > -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University [email protected] http://academic.cleardefinition.com
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
