Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Glaughdram]

This concerns Fortress Mode performance on multiple CPU (or core) systems, the effects of FPS and G_FPS capping, and process affinity setting.

To summarize: The game can utilize greater than 50 percent resources on dual core rigs. Restricting affinity to a single core can reduce performance. Setting G_FPS_CAP too low can also reduce performance.

In my testing, as constants I set FPS_CAP:9999, VSYNC:OFF, and PRIORITY:HIGH. My reported frames per second are estimated (and in no way scientifically achieved).

First: With G_FPS_CAP set to 100 and no affinity restriction the utilization of dwarfort.exe hovers around 60%. In this case the game's effective frame rate averages 1800 fps and peaks around 2000. Restricting affinity to one core produces a utilization of 50%, reducing the frame rate approximately 400 fps.

Next G_FPS_CAP is set to 50. Here utilization is 50-60%, average fps is 1900, and peak fps is 2100. Restricting affinity results similarly as before.

Now I set G_FPS_CAP to 10. This time the utilization is a tad over 50%. However, while I get peaks of 2200 fps at times, the average frame rate is just 1300!

In one more test I set G_FPS to 1000, which produces utilization of 75-90% and an average framerate of 500 fps with peaks in the 600s.

As to what is causing these variations, due to the high utilization while driving a high G_FPS, I surmise that the video driver is resposible. It is my understanding that modern video drivers account for multiple cpus/cores, and include optimizations for such configurations that will engage automatically, and seemingly transparently. When the game's video portion is stressed, it seems that more resources are demanded: Those beyond a single core will be utilized.

In any case, I believe the current understanding of Dwarf Fortress' operation on multiple threaded systems as well as its interaction with openGL is incomplete, and in need of reconsideration.

[Torak]

Anything higher than 200 fps is unplayable anyways.

[ December 19, 2007: Message edited by: Torak ]

[Core Xii]

And kind of pointless to begin with. DF is well suited for software rendering with its extended ASCII graphics.

[sinoth]

quote:Originally posted by Core Xii:
<STRONG>And kind of pointless to begin with. DF is well suited for software rendering with its extended ASCII graphics.</STRONG>

I'm no expert on Toady's code, but I'm pretty sure this statement is completely false.  DF is, at its core, still an OpenGL application that is using textured polygons to render a 2D space.  As such, this whole "ASCII graphics" argument is used incorrectly... the fact that the game looks like ASCII doesn't change the fact that it is simply rendering graphical tiles that happen to look like letters.

You bring up an interesting point Glaughdram.  Some quick searching brought me to this Q&A:

   * Q: Can I use multithreaded OpenGL on Windows or Linux?
   * A: We are not aware of other drivers implementing this feature. It can be emulated by performing the CPU-intensive operations from a second thread with a second, shared context.

It sounds like OpenGL doesn't do any threading automatically.  If this is true, what else could explain your results?  One possibility is that routine Toady uses to cap G_FPS gets more expensive as G_FPS_CAP lowers.  In other words, his capping code is stealing more CPU cycles which results in a lower FPS.

Also, the OpenGL driver doesn't behave very straight-forward at times.  In some of my early 3Dwarf tests, I had situations where increasing the number of polygons on the screen actually -raised- my FPS instead of dropping it.  This was due to my amateur use of OpenGL... more maintenance calls were being sent to the card than actual vertex information, so very little optimization could be done.  While this isn't exactly the case with DF, just wanted to bring it up for consideration.

[Shades]

The 50-60% utilisation on multicore machines rather then the 50% when core restricted could easily be any of the third party libraries used. For example fmod is used for the sound and music.

[Core Xii]

quote:Originally posted by sinoth:
<STRONG>I'm no expert on Toady's code, but I'm pretty sure this statement is completely false.  DF is, at its core, still an OpenGL application that is using textured polygons to render a 2D space.  As such, this whole "ASCII graphics" argument is used incorrectly... the fact that the game looks like ASCII doesn't change the fact that it is simply rendering graphical tiles that happen to look like letters.</STRONG>

Duh, the point I was making was that it doesn't really need OpenGL to begin with just to draw a bunch of simple tiles.

[Glaughdram]

It should be pointed out that of importance here is the apparent performance discrepancy where G_FPS_CAP is lowered drastically.

[mattmoss]

quote:Originally posted by Core Xii:
<STRONG>

Duh, the point I was making was that it doesn't really need OpenGL to begin with just to draw a bunch of simple tiles.</STRONG>

Only thing with that is, I'm guessing, that DF is CPU-bound, which means moving the graphics rendering off the GPU and onto the CPU may slow it down. (Granted, rendering one full screen of ASCII is probably a small portion of the rest of what's going on.)

[Symmetry]

With the number of tiles on the screen it might be possible to get a small improvement in fps if they're being drawn in a bad way, but that's for toady to do.

The results from this thread (http://www.bay12games.com/cgi-local/ultimatebb.cgi?ubb=get_topic&f=11&t=000857) on the menus affecting speed seem to mean there might be something that can be done if toady ever gets around to it    If each tile is drawn as a single call to the opengl driver it'll be much harder on the cpu than if they're all drawn at once in one call using vertex arrays.

[mattmoss]

quote:Originally posted by Symmetry:
<STRONG> If each tile is drawn as a single call to the opengl driver it'll be much harder on the cpu than if they're all drawn at once in one call using vertex arrays.</STRONG>

Yes, forgot about that...

[Lazy_Perfectionist]

On a related note, taking into account the awful combination of vista and intel graphics (cheap laptop), I'm stil surprised to see 30% CPU utilization for something as simple as staring at the main menu. Obviously, that's there in part because the drawing of the screen is offloaded to my cpu instead of my non-existent graphics card, but I'm surprised at quite how much it demands.

As a point of comparison. Dominons 3 with its scrolling 3d background to the menus takes 40%.

So its not like its anything unreasonable, other than me lacking even the cheapest of dedicated graphics. But it is still surprising to see that with graphical frame rate capped at 15 , I'm using 30%, and capped at 50, 50%. All within the first menu, no dwarves or pathfinding involved. If I minimize it, it goes right back down to zero percent.

Point is, it may look ascii, but you'll want a real graphics solution to get the best frame rate. I expect that if I could add add even a bottom of the line graphics card to my laptop (I can't.) or was willing to buy an external one (I'm not) of even dubious quality, I could do a lot better, as long as it had good, dedicated support for opengl.

[schm0]

Graphics card support should be on the top of the list for Toady. The game is already hugely bloated as far as pure processing is concerned. If the graphics were re-directed to the graphics card, the processor would be relieved of having to refresh and update the screen every so many milliseconds.

How hard is it to add driver support to OpenGL?

[Magus]

quote:Originally posted by schm0:
<STRONG>Graphics card support should be on the top of the list for Toady.</STRONG>

Alternatively, ditching OpenGL in favor of ncurses or something and making the default presentation layer truly character-driven might speed things considerably, and would allow features like running across a network.

Preserve appropriate hooks for an alternate tile-based graphical presentation layer like the one we have currently for people who like the graphics and have the power to spare.  It might also help focus where effort can be best spent on future efficiency improvements.

[Lazy_Perfectionist]

Does the game not support graphics cards?

I thought since many cards support OpenGL that it would have been offloaded to a card, if I actually had one.

Well, I really don't have a clue.

[Glaughdram]

quote: The game is already hugely bloated as far as pure processing is concerned.

This, I assume, is an opinion, and not fact.