OSG on steroids

[densm27]

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]

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.

[scrawl]

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]

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.

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.

[sandstranger]

d

[SquireNed]

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.

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]

I'm on Windows, so I can't speak to Linux drivers

Doh! I forget that OpenMW runs on Windows too. Well of course your drivers work... Windows matters to the driver developers. Thanks anyway for responding.

[marchingcubes]

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.

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

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?

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

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.