OSG on steroids

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

OSG on steroids

Post by scrawl » 20 Nov 2015, 02:38

So, I came up with a two line change to OSG that results in a decent speed up for us (about 10% in my test). I don't know if the proposed patch will be merged upstream, it could be problematic from a backwards compatibility standpoint. Either way, the change should be totally safe for OpenMW (famous last words) so feel free to use my OSG fork here and enjoy some extra frames. (Edit: updated link)

In this fork I've also changed the default for OSG_USE_FLOAT_MATRIX to ON so you do not have to mess with cmake settings to get the most optimal performance.

Note you can install different builds of OSG locally, without conflicting with the system wide install. I do it like this:

Code: Select all

# while building OSG
cmake .. -DCMAKE_INSTALL_PREFIX=./install

# while building OpenMW
rm CMakeCache.txt
cmake .. -DCMAKE_PREFIX_PATH=<path/to/install> -DCMAKE_LIBRARY_PATH=<path/to/install>/lib64/ -DCMAKE_INCLUDE_PATH=<path/to/install/>include

# to make sure that OSG finds its plugins, add <path/to/install>/lib64/ to LD_LIBRARY_PATH
Last edited by scrawl on 10 Mar 2016, 19:14, edited 2 times in total.

User avatar
raevol
Posts: 2363
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: OSG on steroids

Post by raevol » 20 Nov 2015, 09:35

I hope they merge it! Is it something we will see rolled into releases or dailies if they don't?

User avatar
scrawl
Posts: 2015
Joined: 18 Feb 2012, 11:51
Contact:

Re: OSG on steroids

Post by scrawl » 20 Nov 2015, 15:45

It was just rejected, so I guess we have a real fork on our hands now. Bring on the pitchforks!

On the bright side, now I can work on more fun optimizations like this one where I don't have to worry about breaking existing OSG applications.
Is it something we will see rolled into releases or dailies
0.37 will stay as is for now (way too late to make more changes). For future releases and daily builds: I wouldn't mind, but it's up to the respective packager.

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 » 20 Nov 2015, 15:56

For k1ll's generic builds it could be interesting, but it'll be a hard push for Debian/Ubuntu. ;)

User avatar
scrawl
Posts: 2015
Joined: 18 Feb 2012, 11:51
Contact:

Re: OSG on steroids

Post by scrawl » 20 Nov 2015, 22:58

Added one more small optimization (single precision quaternions), moved to the master branch, and added a README!

https://github.com/scrawl/osg/

User avatar
raevol
Posts: 2363
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: OSG on steroids

Post by raevol » 21 Nov 2015, 21:41

scrawl wrote:It was just rejected
Whaaaaat. :( What's the story here? Is there any way we could get the extra frames but preserve backwards compatibility? It seems like maintaining a fork is going to be a huge headache...

User avatar
sjek
Posts: 407
Joined: 22 Nov 2014, 10:51

Re: OSG on steroids

Post by sjek » 21 Nov 2015, 22:14

What's the story here?
well it's no use on their angle if somebody at videocard, nasa or some other research (maybe those, dunno, opengl specialised industry engine) starts ratching their head if the program doesn't suprisingly compile or work :mrgreen:
"life is crazy"
"craziness has beauty which only crazies understand" some movie clip in the head.
https://wiki.openmw.org/index.php?title=Testing

User avatar
Ace (SWE)
Posts: 719
Joined: 15 Aug 2011, 14:56

Re: OSG on steroids

Post by Ace (SWE) » 22 Nov 2015, 01:44

I guess I'll be switching my Windows builds over to Scrawls fork after the current release period is over, no use running core OSG if there's an optimized version available after all.

User avatar
ap0
Posts: 241
Joined: 11 Aug 2011, 18:47
Location: France
Contact:

Re: OSG on steroids

Post by ap0 » 22 Nov 2015, 10:22

Scrawl, are you sure that you want to maintain your own fork of OSG? It seems like a lot of work.

User avatar
scrawl
Posts: 2015
Joined: 18 Feb 2012, 11:51
Contact:

Re: OSG on steroids

Post by scrawl » 22 Nov 2015, 19:25

It seems like maintaining a fork is going to be a huge headache...
It seems like a lot of work.
Not really. The patches so far are just a couple of lines each, easy to maintain and easy to transplant between branches if needed. I might go for more wide-ranging changes if there are big gains associated with that but the general plan is to diverge as little as possible, and try to get patches in upstream where possible.

On topic: Found out that most of the time in osg::computeLocalToWorld and osg::computeWorldToLocal (used a lot in our skinning and particle system code) is spent in dynamic_cast's.
dynamic_cast.png
My patch uses the Node::asCamera() instead of a dynamic cast. Doesn't really improve the design issue but much faster:
ascamera.png

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests