[osg-users] Draw threads serialized by default?
robert.osfield at gmail.com
Mon Sep 1 08:33:38 PDT 2008
osgViewer already sets the affinity, and indeed this makes a big
difference to performance when running multi-threaded,
mult-context/mulit-gpu work. The draw dispatch serialization that
osgViewer::Renderer does on top of this makes even more difference on
PCs I've tested. I would guess that a decent multi-processing
architecture like the Onyx would scale much better, it might be that
some very high PC hardware set ups would also scale much better (the
AMD 4x4 motherboards spring to mind as a potential candidate for this
On Mon, Sep 1, 2008 at 4:22 PM, Todd J. Furlong <todd at inv3rsion.com> wrote:
> The post of yours that Paul linked to sounds very similar to something we
> saw with VR Juggler & OSG a while back: terrible performance with OSG apps
> that had parallel draw threads. In our case, VR Juggler manages threading,
> but the same may apply to OSG with osgViewer.
> For us, it turned out that we had to set the threads' affinity to lock them
> to a particular CPU/core. The Linux scheduler moved the threads around and
> thrashed the cache, I believe. Setting the affinity boosted the parallel
> draw performance back up.
> The solution we ended up with is twofold:
> 1. Add a default behavior that sequentially locks draw threads to CPU cores
> (0,1,2,etc. & repeat)
> 2. Use an environment variable to override the default behavior
> (VJ_DRAW_THREAD_AFFINITY, a space-delimited list of integers).
> The default behavior is good for most users, but we can squeeze out a little
> more performance by tweaking the environment variable. For a system with
> two draw threads and two dual-core CPUs, the default behavior locks the draw
> threads to CPUs 0 & 1, but we get slightly better performance if we set
> VJ_DRAW_THREAD_AFFINITY="2 3".
> Robert Osfield wrote:
>> Hi Paul,
>> On Sat, Aug 30, 2008 at 10:19 PM, Paul Martz <pmartz at skew-matrix.com>
>>> Hi Robert -- Prior to the 2.2 release, code was added to serialize the
>>> dispatch. Is there a reason that this behavior defaults to ON? (See
>>> DisplaySettings.cpp line 135.) I have somehow incorrectly documented this
>>> defaulting to OFF in the ref man. Now that I see it's ON by default, I
>>> wonder if this is a bug. Wanted to check with you: should I change the
>>> documentation, or the code? Which is right?
>> The settings has been ON since I introduced the option to serialize
>> the draw dispatch.
>> Just before the 2.6 release I did testing at my end and still found
>> serializing the draw dispatch to be far more effiecent on my
>> Linux/NVidia drivers so I left the option on.
>> In the original thread when I introduced the optional draw mutex into
>> the draw dispatch I did call for testing on the performance impact but
>> I didn't get sufficient feedback to make a more informed decision than
>> just basing it on my own testing. I would still appreciate more
>> testing, as I'd expect that best default setting to vary on different
>> hardware and drivers - I for one would love to see better scalability
>> in driver/hardware.
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
> osg-users mailing list
> osg-users at lists.openscenegraph.org
More information about the osg-users