- Joined
- May 30, 2008
- Messages
- 5,580
- Reaction score
- 2
- Points
- 0
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):
The official response from the DX team:
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:
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):
ClearType affects GDI, and ClearType is an expensive CPU thing. This didn't change between XP and Vista.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.
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.
(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)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.
The official response from the DX team:
(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.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.
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:
The D2D platform is currently being looked at for back-porting to XP, but I have no idea if it will happen or not.Direct2D and DirectWrite: http://channel9.msdn.com/pdc2008/PC18/
Last edited: