OSG on steroids

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: OSG on steroids

Post by scrawl »

I'm not sure whether OpenMW would be impacted by this, but my OpenSceneGraph application was performance-crippled by the openscenegraph viewer class - It sets CPU Affinity for the thread it is created on to CPU 0, which means any threads subsequently spawned from this thread will inherit that.
OSG only does that when the threading model is SingleThreaded. The default threading model is DrawThreadByContext. SingleThreaded is not recommended (speaking for OpenMW anyway).
The issue might affect OpenMW-CS, actually. OpenMW-CS will be run with SingleThreaded threading model if built with Qt5: https://github.com/OpenMW/openmw/blob/m ... t.cpp#L126

I've removed the offending thread affinity setting from the osg fork.
SquireNed
Posts: 403
Joined: 21 Dec 2013, 22:18

Re: OSG on steroids

Post by SquireNed »

corycohen wrote:
SquireNed wrote:I'm on Windows, so I can't speak to Linux drivers
Doh! I forget that OpenMW runs on Windows too. :lol: Well of course your drivers work... Windows matters to the driver developers. :evil: Thanks anyway for responding.
No problem. I mean to set up a double-boot sometime, once I finally get up the nerve to buy a second internal hard-drive and open up the beast to wire it in. I had loosely seated RAM causing crashes this week, and I almost got bold enough to plug in my DVD drive (which is sitting in the case, sans connector). Laziness is my bugbear.
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: OSG on steroids

Post by scrawl »

I've updated the fork to be based against OSG 3.4 release instead of unstable OSG 3.5. This means we are no longer exposed to a memory leak regression in OSG 3.5 that has not been fixed yet. I advise everyone to update.
kornerr
Posts: 2
Joined: 10 Aug 2016, 05:13

Re: OSG on steroids

Post by kornerr »

Hi.

Scrawl, can you please summarize how your OSG fork differs from vanilla OSG?
I'm new here, since my project (not related to openmw) also depends on OSG, I'd like to know the details of the diff, and also the exact reasoning of upstream rejection.

Thanks.
kornerr
Posts: 2
Joined: 10 Aug 2016, 05:13

Re: OSG on steroids

Post by kornerr »

I've found details: https://github.com/OpenMW/osg
But I have questions about the second diff:

* Your change: Added option for single precision osg::Quat's (enabled by default).
* Rejection link: http://forum.openscenegraph.org/viewtopic.php?t=12953

The topic author couldn't justify floats, he had no benchmarks.
I see you claimed your OSG fork actually speeds things up and HAS benchmarks?

I'd like to hear more on that particular issue. I want to help you in arguing with Robert Osfield to make the changes to upstream.
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: OSG on steroids

Post by scrawl »

Oops, sorry for not answering this. I guess I missed your post.
The topic author couldn't justify floats, he had no benchmarks.
I see you claimed your OSG fork actually speeds things up and HAS benchmarks?

I'd like to hear more on that particular issue. I want to help you in arguing with Robert Osfield to make the changes to upstream.
As far as I know OSG doesn't use Quaternions in any performance critical code. The speed up in our case came from the way OpenMW uses them for animation code.

I vaguely suggested making a PR here and didn't get a reply so maybe that should be taken as a no.
Scrawl, can you please summarize how your OSG fork differs from vanilla OSG?
I have updated the readme, maybe that will help. As far as I remember the changes that make the largest difference are:
- Using float matrices (already an option in upstream osg, used by default in the fork)
- Culling nodes with an empty/invalid bounding box. You will have many such nodes if you use skeletal animation. Rejection link: http://forum.openscenegraph.org/viewtopic.php?t=15412
- Improvements to callback speed (OpenMW uses thousands of callback in a typical scene, I'm sure that's a lot compared to other users)
The other changes are relatively minor, but I saw they had an impact in the profiler and the fix was easy so why not.
It should be noted that all the improvements are CPU only and won't help you with a GPU-limited application (which most modern games probably are)
User avatar
Br0ken
Posts: 243
Joined: 02 Apr 2012, 05:54
Location: Siberia

Re: OSG on steroids

Post by Br0ken »

Stable 3.4.1 is released. :)
And according to Robert Osfield's SIGGRAPH presentation, next major release will be 4.0, not 3.6.
User avatar
psi29a
Posts: 5356
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: OSG on steroids

Post by psi29a »

yay :) how much of 3.4.1 is in common with scrawl's fork?

Looking for forward to 4.0 as well...
Post Reply