OSG on steroids

A generic talk on the OpenMW project.
User avatar
scrawl
Posts: 2015
Joined: 18 Feb 2012, 11:51
Contact:

Re: OSG on steroids

Post by scrawl » 29 Nov 2015, 02:37

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: 397
Joined: 21 Dec 2013, 22:18

Re: OSG on steroids

Post by SquireNed » 29 Nov 2015, 21:18

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: 2015
Joined: 18 Feb 2012, 11:51
Contact:

Re: OSG on steroids

Post by scrawl » 04 Feb 2016, 19:48

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 » 10 Aug 2016, 05:19

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 » 10 Aug 2016, 05:27

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: 2015
Joined: 18 Feb 2012, 11:51
Contact:

Re: OSG on steroids

Post by scrawl » 20 Aug 2017, 23:02

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: 198
Joined: 02 Apr 2012, 05:54
Location: Siberia

Re: OSG on steroids

Post by Br0ken » 29 Aug 2017, 07:11

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: 3371
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: OSG on steroids

Post by psi29a » 29 Aug 2017, 07:19

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

Looking for forward to 4.0 as well...

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests