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
