Hi Comicus,

What the WoW layer does is translating 32-bit system API calls into 64-bit equivalent ones, and to convert the return values to make them usable by a 32-bit application. This is actually an overhead, but it is so small that it goes almost unnoticed, at least from a “human” point of view (using benchmark You could detect some difference).

When I first had the opportunity to “put my hands” on a 64-bit OS (Windows XP x64), I tested it with Flight Simulator 2004 and I got exactly the same performances as I used to see in my previous 32-bit Windows XP Home Edition.

The little performance penalty given by the WoW layer could be compensated by better performances in other areas of the Operating System and/or device drivers. Another variable is how the specific CPU You are using performs in 32-bit mode compared to 64-bit. When Intel produced their first 64-bit capable CPU, the Pentium 4 600 series, it was dramatically slower in 64-bit mode (benchmarks told about 20%), probably because it was fundamentally a 32-bit CPU “quickly patched” to support 64-bit extensions. Current CPUs offer almost the same performance in 32- and 64-bit modes.

There are some advanced techniques to gain slight performance advantages in number-crunching applications, especially if floating-point calculations are involved, by converting these into fixed-point using 64-bit integers. I don’t know if such approach has (or will be) used in X-Plane code.

Best regards,
Filippo

The comparisons were 32 and 64 bit X-Plane running on a 64-bit Linux distro.

My recommendation: use 64 bits everywhere.

I’m curious about your test comparison between the 32-bit and 64-bit. Was this comparing a 32-bit Win 7 OS against a 64-bit OS, or did you use the 32-bit WoW functionality of the Win 7 64-bit system? My understanding is that when using the WoW, the system actually has to work a little harder and it decreases performance compared to a native 32-bit build. It may be splitting frog hairs, but I have multiple machines and about to start putting together a new one, wanting to use one of these primarily for flight sim. My original thought was to use the 64-bit system for the master when 10.20 is released and a 32-bit for the scenery rendering, but perhaps this is unnecessary?

-Chris

Hi Ben,

To be honest, I decided to buy this model because at that time Radeon GPUs seemed the ones that didn’t have glitches (at that time You were struggling with screen artifacts on NV hardware). Unfortunately it looks like I was too conservative with the model… now I must live with it, my wife would kill me if she found extra expenses on our bank account…

64 bit will put hair on your face.

Ben,
That’s interesting that you don’t see much, if any, difference in performance between platforms. On my system Linux (highly optimized Gentoo) is almost 50% faster than any version of Windows. This is on a Q9300@3Ghz with a GTX 470. All platforms running the most current NVidia drivers.

Hi Filippo,

It might make more sense to go for a single bigger GPU (in your case a 7970?) than two smaller ones. But check wikipedia for specs and local prices of course.

cheers
ben

Hi Ben,

I’m very grateful for your precious insight!

Basically these are good news for me, since in my later experiments it looks like I’m strongly GPU-bound at the moment (CPU is Intel Core i7 3770 – Ivy Bridge, GPU is AMD Radeon HD 7870): X-Plane never reports CPU utilization above 0.6, while the framerate never goes above 50 fps, unless I turn off quite a bit of the eye-candy (clouds below 30%, no cars, town and forest object to “sparse”). I was in doubt whether going for a second 7870 could improve my situation: based on what You wrote me there are chances it could.

Anyway, I’m aware You are not really satisfied with current Catalyst driver (using 12.8 at the moment here)… I’ll wait for possible improvements of rendering path on AMD hardware before going Crossfire…

Thanks!
Filippo

Hi Filippo,

HDR is indeed a deferred renderer – it’s a deferred renderer that resolves into an HDR surface with a linear color space. Now…

1. It is my understanding that X-Plane _will_ scale with SLI now; the reason NV did not default us to using SLI in their profiles is that we are typically CPU bound on the type of system that the test (one big monitor, one bad-ass video card). For example, if you run a GeForce 680 at 1920 x 1200 with a lot of ren settings, you’re going to max out on CPU due to objs and shadows, not GPU due to HDR and clouds.

2. SLI/Crossfire come in a number of flavors: AFR (alternate frame) should be friendly with deferred rendering engines if they are coded correctly. They are unfriendly to temporal anti-aliasing – the driver has to do some special work to make this case work. Deferred renderers are very unfriendly to _split frame_ SLI and CrossFire, but this case is highly non-optimal anyway because the driver has to push the entire frame to BOTH GPUs (double the “push”) where-as each frame goes out over the bus only once in AFR.

Anyway, if you found a post where someone who works on Unreal 3 says “We don’t play nice with AFR” I’d be curious to see it, but two-pass rendering techniques like deferred rendering should not be fundamentally problematic.

What IS problematic with deferred rendering is anti-aliasing…the G-Buffer has to have its store in “multi-sample” mode – which means 16x FSAA + deferred rendering is 16x the g-buffer storage. Who cares? Well, the problem is that G-Buffers tend to be pretty huge – at a minimum typically 4x the cost of a regular framebuffer. So FSAA + deferred is very frame-buffer expensive, which is why the anti-aliasing options in HDR mode are not as nice (from an anti-aliasing perspective) as in non-HDR mode.