Orbiter on Vista and Win7 (actual data + from the horse's mouth)

[Hielor]

There have been several threads about Orbiter's performance (or lack thereof) on Vista & Win7. This is intended as a discussion thread about solutions to the problem--please refrain from Windows or Microsoft bashing here, and take that to the appropriate threads. This thread is not the place for that sort of thing.

For the last week or so, I've been rallying various people in the appropriate departments (DirectX, WDDM, etc) regarding Orbiter's performance on Vista and Win7 and had several people look at performance traces and diagnostic outputs.

First off, here's the comparison I presented. All of these tests were on the same machine, with the 9.1 version of the Radeon drivers (since the 9.2 version of the Radeon drivers doesn't support Win7). The test pass is the "Glider Launch 1" scenario playback, seen from the glass cockpit mode.

Machine specs:
P4 3GHz
1GB RAM
Radeon 9800 Pro 128MB
Resolution: 1680x1050x32

These images are from the Orbiter framerate monitor. Note that since that window auto-scales to fit the framerate range, these images are not the same scale. Pay attention to the scale. I'll present all of the images first, and then discuss them at the end.

XP with ClearType disabled:

XP with ClearType enabled:

Win7 with ClearType disabled:

Win7 with ClearType enabled:

The numbers fairly well speak for themselves. Note that ClearType causes a big hit on both machines (this is what Doug's VistaBoost addresses). Also note that with ClearType active on XP (and on Win7 both with and without ClearType) the amount of text being shown on the screen (by the playback) makes a big, noticeable difference.

However, for normal gameplay (without the playback text shown), this same machine remained above 75fps throughout an entire ascent to the ISS. Keep in mind that anything above 60fps is essentially wasted in terms of graphics quality, so this is still very, very playable
First few minutes of ISS ascent (Win7, Cleartype disabled):

There is a lot more CPU usage (and correspondingly less GPU usage) on Win7/Vista, though, so if you're on a laptop (or a desktop with especially poor CPU cooling) you may have more problems with Win7/Vista.

So now, what causes the problem? People that chimed in to the discussion had this to say (no, I'm not giving names):

My hunch would be that the app is doing something strange here, and probably mixing D3D and GDI. it’s just that back when the app was written the expensive thing it was doing wasn’t as expensive (and certainly not relative to everything else). I doubt ClearType has any effect on your average D3D game.

ClearType affects GDI, and ClearType is an expensive CPU thing. This didn't change between XP and Vista.

GDI is software emulated in Vista, in XP it’s GPU accelerated, an app that mixes GDI and D3D will be slower on Vista+. Doing a GetDC on a D3D surface in the old DX7 days was cheap and it made mixing GDI and D3D pretty easy to do. Not many applications did this though, most cache font bitmaps and just render them as textures using D3D.

The main problem with this application is that it’s coded to be efficient on operating system, processors and video card hardware that were common back in 1998 (DX7 class hardware), these days the techniques it’s using are not very common and as you can see, have quite the performance impact. XP is better at running this application because of the GDI acceleration and cheaper D3D/GDI interop, these paths were deprecated when we moved to Vista / WDDM.

There is a matrix of components that affect your rendering. You have:

1. Driver model (XPDM, WDDM 1.0, WDDM 1.1)
2. DirectX version (D3D7, D3D9, D3D10, D3D10.1 x 2, D3D11)
3. Hardware capability (D3D7 capable, D3D9 capable, D3D10 capable, etc)
4. D3D DDI being used

Changing things around in this matrix will affect if you have GDI HW acceleration or not. And there are dependencies there.

If you are running with XP, then you are using the XP driver model. This allows the driver to accelerate GDI rendering (but the GDI can punt on stuff too if it wants). D3D9 has a GetDC call in the API, and if you call this on XP there are good odds that you will get a DC that the driver will accelerate with HW on.

If you are running on Vista / Win7, and you have glass with WDDM 1.0, this means that you get no GDI acceleration from anything. GDI will always operate on system memory buffers, and lots of time is spent shuffling these buffers around between system / video memory.

If you are running on Win7 with WDDM 1.1, then *some* operations with GDI are accelerated if the DC you are using has a device bitmap (a video memory backed bitmap). Not all operations are accelerated, and the acceleration in this case is done by the CDD (canonical display driver) calling D3D directly, using both existing and some new DDIs. The new DDIs involved are where the new WDDM model is needed. If you get a DC to paint on, then you have a device bitmap and this will work. If you call GetDC on a D3D10.1 surface in Win7, this will use a device bitmap and will work.

We did not update d3d9 with new performance features in Win7, so GetDC on D3D9 knows nothing about WDDM1.1 device bitmaps and will therefore not be hardware accelerated.

(note that his comments on glass don't apply in Win7, since there is a shim applied which turns off glass when Orbiter is started and turns it back on when Orbiter exits--the transition is *almost* seamless in fullscreen mode and a little shaky in windowed mode)

The official response from the DX team:

Thanks for reporting the problem. In Vista, we made certain design changes associated with the windows display driver model that caused GDI and D3D interop to go significantly slower. Unfortunately, we could not find an easy solution to this problem and chose deliberately to not address it. Starting in Windows 7, we have addressed this problem with a combination of new display drivers and DX10. This requires applications to move to DX10.. it was not possible to address older DX APIs without significant risk and cost.

(Note that saying "this requires applications to move to DX10" means "in order to take advantage of new features," not "if they want to continue working"--previous versions will still work, just not as well as newer ones). I think he's saying that if you use DX10, then you can again have fast GDI/D3D interop, but I'm not 100% sure on that.

So the expensive part is in the GDI/D3D interop. To get around this, Orbiter would have to move away from GDI entirely, but this would break all existing MFDs. I asked what the new "correct" way to do complex drawing to a 2D surface in D3D was, and the response was:

Direct2D and DirectWrite: http://channel9.msdn.com/pdc2008/PC18/

The D2D platform is currently being looked at for back-porting to XP, but I have no idea if it will happen or not.

 

[TSPenguin]

Very good research!
Indeed this is the first time someone actualy compiled this information and more importantly actualy gathered it!
*Thread stickied*

 

[RisingFury]

Thanks for compiling this info.

Hmmm... couldn't there be a support for the old GDI for existing MFD's while implementing a new approach for new developers?

 

[Hielor]

Thanks for compiling this info.

Hmmm... couldn't there be a support for the old GDI for existing MFD's while implementing a new approach for new developers?

I think that would probably be the best way to do it. If you load a "legacy" MFD it uses the current technique of pulling a GDI handle to the region to draw to, but if you have a "new" MFD it does whatever new technique.

It should also be noted that in the ISS ascent I posted, I had the SurfaceMFD and the Align Planes MFD running in the DG 2D panel, at an MFD refresh of .05 (20 Hz), and it was still getting very good framerates. For whatever reason, the playback text has a huge impact on framerate, while the MFDs don't seem to have nearly as much of an effect.

For example, on Win7, sitting on the tarmac in Generic Cockpit mode, turning off each MFD gets me ~5fps (~10fps for both), turning off the HUD gets me ~10fps. Turning off the information display gets me ~2fps.

 

[Rathelm]

Out of curiosity why do GDI calls even need to be made. I thought DrawText can be used without requiring GDI. Does it use DrawLine or something for the MFDs?

 

[Hielor]

Out of curiosity why do GDI calls even need to be made. I thought DrawText can be used without requiring GDI. Does it use DrawLine or something for the MFDs?

MFDs use GDI.

 

[agentgonzo]

For whatever reason, the playback text has a huge impact on framerate, while the MFDs don't seem to have nearly as much of an effect.

I imagine that this is because the text on MFDs is generally 1px wide (the lines that make up the glyph, no the glyph itself) - the 'thickness' or 'width' parameter from memory of the API call. The playback text is thicker, so each glyph will have to draw twice as many lines (the outline, rather than just the glyph) and then perform a fill on the region. Not exactly cheap.

Some other things that I have noticed (and mentioned on the other thread) is that the number of stars drastically affects the performance. Presumably stars are drawn in GDI, so a quick performance increase will be to reduce the number of stars.

Excellent research Hielor. :speakcool:

 

[simonpro]

Keep in mind that anything above 60fps is essentially wasted in terms of graphics quality, so this is still very, very playable

Not strictly true for orbiter, though. The physics engine is tied to the graphics engine, so the more fps you can get the more times per second you'll update the physics.At high time accelerations that can be very important.

 

[Hielor]

Not strictly true for orbiter, though. The physics engine is tied to the graphics engine, so the more fps you can get the more times per second you'll update the physics.At high time accelerations that can be very important.

Time acceleration is cheating Fair point though. This computer is an XP-era computer, though--any computer that came with Vista pre-installed is (wow, i just had a Thought, see below) going to have higher specs and could probably easily stay above what that computer was getting on XP.

--------------
Thought: Cores! Orbiter is (largely) a single-threaded game, so it would do well on a single-core processor with a high clock (and not-so-well on a dual- or quad-core processor with a lower clock). I guess a "simple" initial fix for that would be to have separate physics/graphics threads, but I have no idea how that would actually work.

For example, my desktop is an Athlon 64 3400+, while my laptop is a Core 2 Duo T5550 (1.83 GHz). The desktop has a GeForce 6800GT, while the laptop has an 8600M GS. On paper, then, the laptop is "better" than the desktop (and it does outperform the desktop in newer games), but if Orbiter's only using one core, that would explain why the laptop is so much worse than the desktop. That also explains why the desktop at work didn't have as much problem on Vista.

Does the splitting of the graphics client from the Orbiter core in the next version move toward using multiple cores, or is still primarily single-threaded?

 

[RisingFury]

Some modifications would have to be done, but it looks to me that it would be possible to have the graphics part run on another core. OpenMP is a good choice...

 

[GaryP]

Thanks for the tip about ClearType and vista, it's made a vast difference to the smoothness of Orbiter on my laptop.

I'm using a laptop with the following specs:-

• Vista 64bit
• 2.4GHz Core 2 Duo
• NVidia GeForce 8800M GTX
• 4GB Ram

Scenario Final Approach, Res 1920x1200 @ 32bpp. Value in brackets is with VSync disabled.

Stock 2006 Install
Gives 14fps (19fps)
With VistaBoost gives 29fps (71fps)

Stock 2009 Beta
gives 19fps (21fps)
with VistaBoost 29fps (51fps)
orbiter_ng with D3D7Client 21fps (26fps)
orbiter_ng with VistaBoost 59fps (81fps)

The results with VSync off are as expected, but the most interesting result imo is running orbiter_ng with the D3D client and vistaboost gave a stable 60fps with VSync enabled.

Anyhow, I thought someone may find these results useful and besides the forum is telling me to make a post or risk my account been purged at some possible future date

 

[Istochnikov]

Notify to Vinka, please: Left Shift + Numpad keys don't work on Win 7.

My laptop: IBM-Lenovo Thinkpad T60
-Intel Core 2 Duo t5550
-1,5 GB RAM
-Windows 7 Release Candidate 7100
-DirectX 11
-Intel GM945L (Integrated Intel Extreme Graphics X3100)
-Orbiter 2006P1 running smoothly.

I should notify that some scenarios with high poly meshes, slow down too much Orbiter. Example: Any Scenario with Papyref's Kourou ELS or Kulch's Area 250

 

[Hielor]

<snip>
-Intel GM945L (Integrated Intel Extreme Graphics X3100)
<snip>
I should notify that some scenarios with high poly meshes, slow down too much Orbiter. Example: Any Scenario with Papyref's Kourou ELS or Kulch's Area 250

With an integrated graphics chip you should expect Orbiter to slow down when using high-poly meshes.

 

[dansteph]

Not strictly true for orbiter, though. The physics engine is tied to the graphics engine, so the more fps you can get the more times per second you'll update the physics.At high time accelerations that can be very important.

Also there is no blurring as in film when there is high speed movement. You can clearly see a difference beetween 60FPS and 140FPS. Above that I don't think it matter so much effectively.

60FPS is pretty slow I had that FPS on my 6 years old computer. Now I have currently 240/350 FPS on my three years old computer running XP.

I used to be a fervent microsoft supporter, this is not anymore the case since vista.

Dan

 

[Hielor]

Also there is no blurring as in film when there is high speed movement. You can clearly see a difference beetween 60FPS and 140FPS. Above that I don't think it matter so much effectively.

60FPS is pretty slow I had that FPS on my 6 years old computer. Now I have currently 240/350 FPS on my three years old computer running XP.

I used to be a fervent microsoft supporter, this is not anymore the case since vista.

Dan

Assuming that the 60fps is synchronized to the refresh rate of the monitor, then there will be no perceivable difference between 60 and 140. In fact, with 140, it may look worse due to tearing effects due to not being an exact multiple of the refresh rate.

Hardware support for D3D/GDI interop was dropped in Vista to enable hardware manufacturers to move forward without always needing to support ten-year-old features that hardly anyone uses. That's the key here, that Orbiter is one of very few programs that uses this method. Modern games did not suffer the performance hit that Orbiter did.

 

[Istochnikov]

With an integrated graphics chip you should expect Orbiter to slow down when using high-poly meshes.

I'm partially in accord with you, but with the Papy's ELS it shouldn't slow down so far (on Windows XP it runned with an average of 20 FPS). The LC 250 is another BIG problem... I should say that i'm a hig-poly developer and i use my laptop for test if the developments work in well. Except with the LC 250, my Hi-poly sats run well even in an Overload scenario that i use for testing.

I must report one thing more: The give-me-all-you-have manner to use the CPU that Orbiter has. It is another thing to refine. I have a desktop with an AMD Athlon 64 3200 (2GHz) and the 100% of the CPU is used when Orbiter runs!!! (this on Win XP). I've observed the comments aboiut the CPU use by orbiter in a multicore CPU, and i can note in the comsuption stadistics, that both cores work at the same percentage. Possibly the multicore proccessing AND/OR/BUT-NO-XOR migrating to OpenGL (Artlav's OGLA?) could modify all the problems. I'm a computer programming noob, so my impressions possibly couldn't be correct

 

[Hielor]

I'm partially in accord with you, but with the Papy's ELS it shouldn't slow down so far (on Windows XP it runned with an average of 20 FPS). The LC 250 is another BIG problem... I should say that i'm a hig-poly developer and i use my laptop for test if the developments work in well. Except with the LC 250, my Hi-poly sats run well even in an Overload scenario that i use for testing.

If you were only getting 20fps on XP, then on Vista or 7 you should expect much less from Orbiter...

 

[tblaxland]

I must report one thing more: The give-me-all-you-have manner to use the CPU that Orbiter has. It is another thing to refine. I have a desktop with an AMD Athlon 64 3200 (2GHz) and the 100% of the CPU is used when Orbiter runs!!! (this on Win XP).

That is a feature. Orbiter aims to run as fast as possible in order to reduce the time step size and hence reduce integration errors.

I've observed the comments aboiut the CPU use by orbiter in a multicore CPU, and i can note in the comsuption stadistics, that both cores work at the same percentage.

In a multicore setup, Orbiter should only use 100% of one core.

 

[Andy44]

Can anyone explain to me why 16 fps works fine on my 5-year-old Win-XP laptop with no video card, but my bran new Vista machine with a video card and a faster processor looks terrible with anything less than 30 fps?

 

[Hielor]

Can anyone explain to me why 16 fps works fine on my 5-year-old Win-XP laptop with no video card, but my bran new Vista machine with a video card and a faster processor looks terrible with anything less than 30 fps?

Define "looks terrible"?

And I don't know about Orbiter, but other games (Oblivion) seem fine at 20fps on Vista to me. Possibly something else that Orbiter is doing which isn't kosher.