OSG on steroids

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
densm27
Posts: 20
Joined: 02 Jun 2014, 18:34

Re: OSG on steroids

Post by densm27 » 27 Nov 2015, 10:56

Scrawl, what settings are you using for these tests? Asking because my average Balmora is "only" 150-160 on 1920x1080 with water shader off, AA off and default exterior grid size. My PC is way less powerful (3.8Ghz i5-3570 and a GeForce 770), but can it really lead to twice lower performance?

SquireNed
Posts: 397
Joined: 21 Dec 2013, 22:18

Re: OSG on steroids

Post by SquireNed » 28 Nov 2015, 17:07

densm27 wrote:Scrawl, what settings are you using for these tests? Asking because my average Balmora is "only" 150-160 on 1920x1080 with water shader off, AA off and default exterior grid size. My PC is way less powerful (3.8Ghz i5-3570 and a GeForce 770), but can it really lead to twice lower performance?
Performance is really something that falls exponentially, especially rendering performance. IIRC benchmarks are typically done at 1024x768, which renders about 1.2M fewer pixels than you did (out of the ~2M pixels total you rendered) each frame. I went from ~150 FPS in testing to around 70 by turning on a handful of graphics settings, and I'm running a beefy 970 that gets 60 FPS on almost everything.

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

Re: OSG on steroids

Post by scrawl » 28 Nov 2015, 17:43

I run my tests at 1024x768, because I'm more interested in optimizing CPU performance (it's hard to tell what's going on on the GPU, and we already do things like state sharing and state sorting that help lighten the GPU workload).

After the most recent batch of optimizations, it turns out that OpenMW is now mostly GPU-limited on my system at 1680x1050 and 8xAA.

corycohen
Posts: 30
Joined: 26 Sep 2012, 03:05

Re: OSG on steroids

Post by corycohen » 28 Nov 2015, 18:15

SquireNed wrote:I'm running a beefy 970 that gets 60 FPS on almost everything.
I'm planning on buying a GTX 970 soon (probably Monday) because I've had it with my crappy AMD driver support in Linux. Are you happy with your purchase? Have you experienced any driver bugs? Do you have a multi-monitor setup (the apparent cause of most of my AMD driver bugs)?

I want to be sure that I've moved 100% any performance problems onto the CPU so that I can understand better where the performance issues in OpenMW really are. I was pretty pleased when scrawl committed a fix for the locale version of tolower() the other day. When he posted the screenshots of kcachegrind I went and got educated, and my first test run identified dynamic casting in tolower and couple of other strings functions as the primary issue. I guess that means that I did it correctly. :o

Anyway, it seems that having a 970 will eliminate any concerns about being GPU bound (at least for a while). It'll be interesting to see what happens when shadow shaders are implemented again.

User avatar
sandstranger
Posts: 434
Joined: 19 May 2014, 19:53
Location: Oblivion

Re: OSG on steroids

Post by sandstranger » 28 Nov 2015, 19:49

osg in prebuilt Android dependencies was replace on this fork

SquireNed
Posts: 397
Joined: 21 Dec 2013, 22:18

Re: OSG on steroids

Post by SquireNed » 28 Nov 2015, 20:09

corycohen wrote:
SquireNed wrote:I'm running a beefy 970 that gets 60 FPS on almost everything.
I'm planning on buying a GTX 970 soon (probably Monday) because I've had it with my crappy AMD driver support in Linux. Are you happy with your purchase? Have you experienced any driver bugs? Do you have a multi-monitor setup (the apparent cause of most of my AMD driver bugs)?

I want to be sure that I've moved 100% any performance problems onto the CPU so that I can understand better where the performance issues in OpenMW really are. I was pretty pleased when scrawl committed a fix for the locale version of tolower() the other day. When he posted the screenshots of kcachegrind I went and got educated, and my first test run identified dynamic casting in tolower and couple of other strings functions as the primary issue. I guess that means that I did it correctly. :o

Anyway, it seems that having a 970 will eliminate any concerns about being GPU bound (at least for a while). It'll be interesting to see what happens when shadow shaders are implemented again.
I'm on Windows, so I can't speak to Linux drivers, but for the most part I only have driver issues with cutting-edge games (for instance, when Rainbow Six: Siege was in beta and I hadn't updated my drivers for a while).

The big thing with GPU bottlenecks are that you can almost always hit limits with a GPU and high-resolution games, but they're easier to work around than CPU bottlenecks (by turning down settings, etc.).

corycohen
Posts: 30
Joined: 26 Sep 2012, 03:05

Re: OSG on steroids

Post by corycohen » 28 Nov 2015, 20:37

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.

marchingcubes
Posts: 1
Joined: 28 Nov 2015, 22:46

Re: OSG on steroids

Post by marchingcubes » 28 Nov 2015, 22:56

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.

This pretty much meant in my case, that the app I spent a bunch of time multithreading was stuck on a single core until I added code in my threads to unset the CPU affinity, at which point it went from a jerkfest to buttery smooth.

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

Re: OSG on steroids

Post by scrawl » 29 Nov 2015, 00:18

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.

This pretty much meant in my case, that the app I spent a bunch of time multithreading was stuck on a single core until I added code in my threads to unset the CPU affinity, at which point it went from a jerkfest to buttery smooth.
Thanks for the tip. I was wondering if that could cause problems. The CPU affinity setting for Linux was added in OSG 3.4, but I didn't notice a performance regression when upgrading. I'll do a test without cpu affinity to see if there's any difference.

Out of curiosity, how does the cpu affinity mask interact with hyperthreading? Is the affinity set to physical or to virtual cores?
Last edited by scrawl on 29 Nov 2015, 02:22, edited 1 time in total.

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

Re: OSG on steroids

Post by scrawl » 29 Nov 2015, 02:16

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).

I noticed the draw thread's cpu affinity is always set to cpu 1, but that doesn't seem too harmful since no new threads are spawned from the draw thread.

Post Reply

Who is online

Users browsing this forum: Baidu [Spider] and 2 guests