CPU and Single Core Implications

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
Xenuria
Posts: 25
Joined: 26 Feb 2017, 22:35

Re: CPU and Single Core Implications

Post by Xenuria » 04 Dec 2017, 16:11

I think I would feel better if I knew what I could do to allocate more resources to the game on a hardware level. The only issues I have are loading Cells, the game halts for a good 2 seconds and that is realistically the only time the OpenMW client falters at all for me.

I let the game use as much RAM as it wants, but it still seems like it only uses a fraction of the VRAM it could.

CMAugust
Posts: 64
Joined: 10 Jan 2016, 00:13

Re: CPU and Single Core Implications

Post by CMAugust » 04 Dec 2017, 16:28

I'm not sure using a boatload more VRAM would make a lot of difference, at least not in a sensible way. One of the actual developers can pull me up if I get any of this wrong, as I'm just a layman, but I'm going into a little more detail about OpenMW's current performance.

Just to give an idea of what the actual bottleneck is and what isn't, here's a screenshot with Scrawl's lovely distant terrain enabled and viewing distance cranked to max. This was taken directly over Seyda Neen with the default exterior cell count of 1. There is a performance penalty to be sure, but as you can see, this in itself is not giving my hardware too much trouble.

But look what happens when I travel to Ebonheart: same exact settings, but the framerate is almost cut in half. Ouch! Sadrith Mora is almost as bad. And I believe the culprit, indicated by the yellow bar, is the massive number of draw calls. This is the sort of thing you really don't want to see; for comparison, here is what the physics bar looked like in one of the worst spots before the movement solver was improved.

Turning off distant terrain or just lowering the view distance to default alleviates this issue to somewhat less crazy levels in both cases, but you can still see how high it is to everything else (keep in mind also this is with maxed out graphics options). The reason why lower view distance helps is simply because there's less stuff the CPU has to ask the GPU to draw. Now, whenever you cross a cell border a number of new cells are loaded all at once in front of you - all those objects appearing in an instant leads to an explosion of draw calls. With distant terrain and max view distance, I've seen draw calls briefly jump over 50 as I stepped into certain regions. As for why the draw calls are so ridiculous - I know you were a part of this discussion, but it's worth repeating Scrawl's comments on the matter: viewtopic.php?f=3&t=4207&p=48137#p48137

Even with no extra engine optimization at all, I get the feeling we'd see a smoothness in gameplay and cell transitions comparable to Skyrim or better just by fixing the game assets. However, since nobody's talked seriously about undertaking such a project, I'm holding out hope we'll still see some performance improvements yet ;)

Xenuria
Posts: 25
Joined: 26 Feb 2017, 22:35

Re: CPU and Single Core Implications

Post by Xenuria » 04 Dec 2017, 16:37

Behold 2 videos.

https://youtu.be/tMyubBLTLLs - https://pastebin.com/UUEvqZcA
https://youtu.be/4W-32l1OfMI

Notice the sharp difference?

The entire time Memory never goes above 3.5GB of RAM and it never uses more than 17% of my 1080 GPU.
If the bottleneck IS CPU than we have a really sad problem on our hands.

If this game gets the single best optimizations in the history of programing, it will still have problems because it's single core. I know we can't go back in time and whack somebody on the head for saying single core was the only way to do this, but what we can do is try to find creative workarounds. I am starting to suspect the engine is 32-bit, I hope that is not the case because that would be comical and tragic.

User avatar
psi29a
Posts: 3448
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: CPU and Single Core Implications

Post by psi29a » 04 Dec 2017, 17:29

it's 32-bit only if the binaries downloaded are 32-bit.

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

Re: CPU and Single Core Implications

Post by scrawl » 04 Dec 2017, 17:38

The FPS is exactly 60 here, are you sure VSync is not enabled?
Well, the FPS counter isn't visible, but what I can see is:

* You're moving at ludicrous speed that is unlikely to happen during gameplay.
* Your Cell Preloading feature is completely broken because you've set in your CFG file 'prediction time = 250' (normal value is 1). That's probably why you see loading screens. Sorry, the engine can't predict your position 4 minutes in the future.
* The second video is choppy, as expected with a greater cell load distance. Cell load distance is mostly to be used for scenic screenshots, it's not meant to be optimized for real time gameplay. An optimized version of rendering distant cells would be possible in the future, I've outlined this here.

I think most of your problems boil down to changing settings that you don't understand. As the documentation states, you need to be careful with those. Try to revert to a default copy and then change one setting at a time, making sure you're still happy after each change.
The entire time Memory never goes above 3.5GB of RAM
What do you expect the extra memory should be used for? Memory is for storage, you can't use it for computations or magically increasing your FPS.

To make more use of memory, you can:
* install high-res texture / mesh replacers,
* use a high resolution display & turn up anti-aliasing,
* increase cell-preloading settings,
* know that having memory left over is perfectly normal, and leads to benefits in the form of files being cached by your OS.
never uses more than 17% of my 1080 GPU
I'm not sure where that figure is from, but on the first video the orange bar is mostly full, your GPU appears to be used about 80% in some scenes.

But, you've set 'framerate limit = 100', so in the cases where the FPS could have gone higher than that, of course the GPU usage will plummet.

During loading screens or stutters caused by not using Cell Preloading, of course the GPU will not be used, either.
single core
It's not. The game uses 4 threads by default. You can use more if you want, go increase 'preload num threads = 1' (more than 3 is probably not useful, though)
Even with no extra engine optimization at all, I get the feeling we'd see a smoothness in gameplay and cell transitions comparable to Skyrim or better just by fixing the game assets. However, since nobody's talked seriously about undertaking such a project, I'm holding out hope we'll still see some performance improvements yet ;)
Probably not from me, or at least I can't think of any ATM; apart from Vulkan, which would be a very big undertaking. There was some talk of a vulkan-based successor to OpenSceneGraph, but not much seems to have happened on that front yet.
the engine is 32-bit
This statement doesn't make sense in the context of an open source engine. Your computer is 32 bit or it isn't. The engine can be compiled as a 32 or 64 bit binary as you wish. If you look on our download page, we do offer both.

User avatar
Lagahan
Posts: 41
Joined: 16 Aug 2014, 11:24
Location: Ireland

Re: CPU and Single Core Implications

Post by Lagahan » 04 Dec 2017, 20:55

psi29a wrote:
04 Aug 2017, 14:13
OpenMW is multi-core, but the physics sub-system isn't. That's the bottleneck.
Not all the time, draw calls can be an issue in places (Balmora, Ebonheart, big towns in general), but there's not much we can do about given how characters are rendered and how the game was designed for low draw distance with a fair bit of detail within that draw distance.
If OSG went towards Vulkan it might improve that but I'm not a low level graphics programmer so I don't know if it would improve anything or not, and the work involved would probably be huge - more important to hit 1.0 first.

As for OP's question, I'm on a 4.6GHz 6700k with a 1080ti, however I upgraded from a 4.8GHz 2500k and despite the clock decrease* I still noticed an increase in performance on OpenMW since the Nvidia drivers' multi-threading handles draw calls better on OpenGL applications with a few more threads to play with.

*(Intels really slow incremental IPC improvements might have actually negated the 200MHz gap in those 5 years though, my RAM is twice the speed, frametimes in CPU limited games have become more consistent with more threads)

To be honest the biggest jump was going from an R9 290 to a 1070 even with low GPU usage on both since AMD's OpenGL driver CPU overhead is, for the lack of a better term, cack, especially with the water shader enabled.

I've nabbed a quick video here on Ace's 0.43 release with the exact same settings as that pastebin barring:
prediction time = 1 (250 made it run HORRIBLE)
framerate limit = 235 (240hz monitor)
Vsync = false (G-sync is on)

https://www.youtube.com/watch?v=QUq3wU4 ... e=youtu.be

Sure there's still points where its choking on draw calls in towns but its nowhere near as bad as what you're experiencing. As scrawl said reset your graphics settings, be very careful when tweaking them and you should be fine with a 2700K, if needs be overclock it, if its still stuttering on cell loads get an SSD and if its STILL giving issues after that then the bottleneck is somewhere else, probably software or driver configuration outside of OpenMW.

Small feature culling should also always be on, I usually bump it up to 4 pixels for 1080p and 8 pixels if I'm downsampling. If you can see something pop in you're sitting way too close to the screen.
Distant terrain is also very new to the OSG renderer and nowhere near optimized so just steer clear of it for now.

Without recording software and with mostly default settings, 3840x2160 downsampling, I usually get 235fps capped outside of places with tons of models like Balmora, Ebonheart, Dren plantation, etc where it drops to 100ish.
Specs: Core i7 6700k @4.6GHz, EVGA GTX1080ti SC2 Hybrid @2GHz,
32GB RAM @3.2GHz, Windows 7 Pro x64

CMAugust
Posts: 64
Joined: 10 Jan 2016, 00:13

Re: CPU and Single Core Implications

Post by CMAugust » 04 Dec 2017, 21:55

scrawl wrote:
04 Dec 2017, 17:38
The FPS is exactly 60 here, are you sure VSync is not enabled?
Yes, I have a 60hz monitor, so that's all I need. Well, that and I was fed up with my GPU squealing every time I loaded OpenMW and hit 1000fps on the title screen. For now, my dream is for OpenMW to deliver a perfect 60fps and frame pacing at all times. Those screens were just to demonstrate the still considerable draw calls even with default viewing distance. The same area in Ebonheart with vsync off is around the 80 mark, though it can dip to the low 70s when moving around the area. This is with a gtx 970.
Last edited by CMAugust on 04 Dec 2017, 22:37, edited 1 time in total.

Xenuria
Posts: 25
Joined: 26 Feb 2017, 22:35

Re: CPU and Single Core Implications

Post by Xenuria » 04 Dec 2017, 22:17

scrawl wrote:
04 Dec 2017, 17:38
* You're moving at ludicrous speed that is unlikely to happen during gameplay.
I think you may have just outed yourself there. The whole point of Morrowind was that you became a literal god and could jump continents, pickpocket from orbit, command entire towns with magic, etc. It's written into the main quest and is a core part of the story. The fact that your average player has the expectation going in that OpenMW will some day be able to handle this is an unfortunate consequence of the original game play style.

Everything else you said makes sense though. I will do some tweaking and play around. See if I can find ways to make it run better and then I will share my insights.


https://youtu.be/hIn8v9v-h6k

Here is a video of me loading all grids with max view distance. Pretty stable at 1.5 fps.


Edit: My logic with prediction was that I could try and keep stuff in memory so it wouldn't need to load and cause stutter. Like if I could preload as though cell load was 4 but have actual cell load at 2, that way in either direction there would be a buffer.

Eli2
Posts: 45
Joined: 27 Nov 2011, 08:23

Re: CPU and Single Core Implications

Post by Eli2 » 04 Dec 2017, 22:30

Xenuria wrote:
03 Dec 2017, 21:17
I suppose the confusion for me as an outsider with no knowledge of development ...
Xenuria wrote:
04 Dec 2017, 16:37
If this game gets the single best optimizations in the history of programing ...
I get the feeling Xenuria is a troll.

Xenuria
Posts: 25
Joined: 26 Feb 2017, 22:35

Re: CPU and Single Core Implications

Post by Xenuria » 04 Dec 2017, 22:35

Eli2 wrote:
04 Dec 2017, 22:30
Xenuria wrote:
03 Dec 2017, 21:17
I suppose the confusion for me as an outsider with no knowledge of development ...
Xenuria wrote:
04 Dec 2017, 16:37
If this game gets the single best optimizations in the history of programing ...
I get the feeling Xenuria is a troll.
Would have to be a really high effort troll considering I am the only person who does niche videos for OpenMW at this scale. Nobody else did TK from Orbit or loaded all grids in 4K.
I legit have no programing chops whatsoever so my view is going to seem stupid and moronic to some people here. That's fine. I am humbled by the skills of the community here.


That said I made some changes like scrawl suggested and noticed that Viewing distance dosn't really cause much issues as long as cell load is 1.
I still have it set to 413455 for when I was loading 50 grids. Getting decent fps everywhere and a good view. I think when distant statics happen this will be really nice.

Post Reply

Who is online

Users browsing this forum: Yahoo [Bot] and 1 guest