How Framerate Dies - Glitching

Back in the good old days (that would be X-Plane 6), X-Plane's framerate would suffer in two ways as you cranked up the rendering options:

1. For most features (more visibility, more autogen) as the CPU and GPU became more heavily loaded, the framerate would gradually decrease.
2. If you ran out of VRAM (that is, the working set of textures needed per frame was more than your card's VRAM) framerate would really die fast - think 2 fps.

The reason for this second behavior was that computers couldn't shuffle textures between main memory and VRAM fast enough to render a frame in a 30th of a second.

As computers have gotten faster, this second behavior has gone away - modern cards, with fast PCIe 16x busses, can transfer textures from system memory to VRAM pretty fast - fast enough to have the working set be (slightly) larger than VRAM and still fly. So as texture memory increases, framerate decreases more gradually.

However, a new behavior has emerged: "glitching". You may have noticed that when you've got your computer set to the ragged edge of the rendering settings, as you turn the camera, the framerate will stutter for a few frames, then return to a relatively high rate (40-50 fps).

What's happening is: the working set of textures and geometry needed by X-Plane just barely fit in VRAM. But when you turn your head, a different set of textures and geometry are needed. While the card sorts out what is needed and what isn't, it spends some time needlessly shuffling textures, and eventually reaches stability, with only what's needed in VRAM, and framerate stays high.

Glitching has emerged as a mode of performance degredation because over time we've cut down the amount of "stuff" (textures and geometry) x-plane needs to draw a frame to only what's really absolutely needed. This means there is less intersection between the working set in one view and another, and it also means you can get closer to the edge of your hardware.

So my view on glitching is basically "too bad". If the working set weren't as carefully trimmed, you wouldn't have glitches, but the framerate would be entirely low, not entirely high. The only solution is to turn down settings that increase the working set (object density, world LOD, tex res, forests...) until the computer can run without glitches.

An even stranger variant of this: users sometimes report framerate getting "stuck" at 19 fps and then coming back when they change apps. The problem is that the driver doesn't know exactly what the best order of textures to keep in VRAM vs. shuffle is...as the view changes, sometimes the driver ends up with a non-optimal decision about what stays in VRAM and what goes, causing framerate to drop. Changing which app is in the foreground fixes this by temporarily pushing a lot of items out of VRAM, at which point the driver makes a different decision by luck.

Again, the solution is simple: turn down rendering settings to get the working set smaller than VRAM.

Basically, if the working set is smaller than your amount of VRAM, you should have even framerates, proportional to rendering load.

If the working set is greater than VRAM, the driver may find an optimal way to shuffle things and only decrease fps a little, or it may find a non-optimal way to shuffle and you'll get terrible fps, and that shuffle can change on the fly, causing framerate to fluctuate all over the place.