Monday, December 11, 2006

Musings on Framerate (Just a Test)

I will admit...this post is really just a test to see if the blog is still working. I just got my blogs moved to the new "blogger beta" so I want to make sure the feed still works.

One user posted this comment in response to my rant on framerate...

"What I wonder in X-Plane and FS2k4 as well is, why there is no better automatic regulation which automatically set object density, object quality and so on based on the current frame rate...."

This is a good idea that has been suggested before. However when I tried it, it worked very poorly for two reasons:
  1. Because we reduce visibility as well when fps fall, if we also tie object density/distance to framerate, then we have two separate variables responding to framerate. The result was oscillations. Think of framerate and visibility as a (hopefully) dampened oscillator. With two variables, getting the oscilation out is a lot harder.
  2. the relationship between object density as the sim controls it and framerate is not a static one, because object density (relative to other scenery complexity) varies a huge amount with locale. In the mountains, backing down objects won't save your framerate. In the city it will. So coding the "spring factor" for that oscillator is very difficult.
That doesn't mean we won't try this again in the future - that's just what happened when I tried my first naive attempt.

Other comments reflected users either hoping for more fps from existing hardware (there's a lot of that on X-Plane.org) or saying that X-Plane runs well on their modern shiny computer.

Here's some stats for you:
  • Radeon 9200: 1000 MT/sec 6.4 GBi/sec
  • GeForce 5200 FX (64-bit version): 1000 MT/sec 2.7 GBi/sec
  • Radeon X1950XTX: 10,400 MT/sec and 64 GBi/sec
  • GeForce 7900 GTX: 15,600 MT/sec and 51.2 GBi/sec
(These numbers come from Wikipedia - I make no promises.) The first number MT/sec is mega-texels per second and represents how many millions of pixels* the card can fill in. GBi/sec is gigabits per second of data transfer from VRAM to the GPU. Neither of these are perfect predictors of card speed (but they do limit your ability to run with a lot of FSAA) but they do illustrate something:

The difference between the speed of the smallest and biggest graphics cards is over 15x for fill rate and over 25x on memory bandwidth! That's the equivalent of people trying to run with a 3 ghz and a 120 mhz CPU! Anyone running with a 120 mhz Pentium out there? Definitely not - our minimum CPU requirements are ten times that.

In other words, the high rate of technology improvement in graphics cards has left us with a ridiculously large gap in card performance. (In fact the real gap is a lot worse - the 9200 and 5200FX are not even close to the slowest cards we support, and I haven't even mentioned the new GeForce 8 series, or pairings of two cards via SLI or Crossfire.)

* Pixel or texel? Technically a texel is a pixel on a texture, at least by some definitions, but perhaps more important is that these numbers indicate fill rate at 1x full-screen anti-aliasing...you would expect them to fill screen pixels at roughly 1/16th the speed at 16x FSAA. This is actually good - it means that FSAA can help "absorb" some of the difference in graphics power, making X-Plane more scalable.

3 comments:

Jilles said...

A nice improvement would be to make the object density at least run-time configurable. Right now if I "enter the fog" my only option is to reconfigure x-plane and restart it (takes a few minutes). In practice this means that most of the time, I'm looking at scenery of less quality than my hardware is capable of because of a few areas that bring it to its knees. I have to keep it configured conservatively because of a handful of problematic areas.

A second improvement would be to make the settings a bit more fine-grained. The visual difference between default and tons is huge and so is the performance gap. Having some intermediate settings would be helpful.

Benjamin Supnik said...

I'm not sure what you mean by "runtime" - I would define that as anything while the sim is running, of which we have two settings.

- Object density is run-time but requires a scenery reload (it doesn't reset your flight) so it's moderately inconvenient to change, but still accessible. The reason for the reload: we actually delete the filtered objects from memory with this setting...this is important because it cuts down the RAM footprint for users who aren't going to use the detail anyway.

- World LOD cuts down far away objects and is completely dynamic.

Perhaps you mean automatic or dynamic? There's definitely no need to restart the sim for these settings to take effect. (Restarts were necessary in the past.)

Fine grained settings: email Austin and tell him you want more granularity. :-)

Anonymous said...

this comes a bit late I think, but anyway... about number of objects. How about having a parameter which let you configure the maximum about of displayed objects per tile? Then on sparse areas it could load every available object but when flying on more tense areas it starts reducing the percentage thus avoiding fog?