You may have had 32 MB of VRAM 6-7 years ago…I had 8 MB. You have 3/4 of a gig now, which is not at all common.

You’ll need to install third party add-ons to take advantage of this particular kind of hardware surplus.

I actually wonder who can run X-plane with 32 MB VRAM-machine anyway. Why to support something such low spec?

I don’t know anyone who would have 32 MB VRAM _and_ be interested in flight sims, even the MSFS people are using higher spec cards. Minimum spec HW could be rather 64 to 128 MB (IMHO) today. I had 32 MB something like 6-7 years ago (it was about the last time I had Windows, and was running Win98) and it sounds very ancient to me. X-plane most likely is quite unusable on a such machine anyway, why bother supporting them. I have used this GF8800GTX with 786 MB VRAM now for over a year and it was purchased almost exclusively for the X-plane, because there are not so many other uses for the high spec video card in a Linux machine these days (there are not that many games out there), and I would love to get more realistic scenery out of it as there is plenty of texture memory and the GPU isn’t a slow one and could do a lot more than it is doing now.

Regarding the rest of your post…

“X-plane should, in addition to having 64-bit version, agressively use thread-pools for calculating the geometry “

I have no idea what calculating the geometry means, and to be blunt, I don’t think you can be in a position to suggest engineering solutions to an application where you don’t know the internal architecture or existing code.

The overall gist of your post seems to be “X-Plane should utilize the hardware resources I have”. But…I would say: you should get the hardware resources we utilize. 🙂

That last point is sort of a joke, but the truth is that we must utilize hardware resources based on…

– The entire community’s resources across the board and
– What we can incrementally change based on the constraints of an existing application.

To that first point, having 1 GB of RAM isn’t going to be that useful for the default scenery, which must be able to scale all the way down to 32 MB of VRAM — even if you run on “extreme” it won’t all be used. There may be custom orthophoto packages that can use this much VRAM, but it’s getting outside the profile that makes sense.

to the second point, moving to multi-core takes time. X-Plane has used multi-core resources more heavily in every major architectural change we’ve made over the last few years. But these are also the most complex and difficult refactoring tasks we face, so the progress is not going to be fast. We can’t just flip a swtich and be multicore.

We would like to have as soon as possible a 64-bit variant that would be optimized for multi-core CPUs.

Our setup currently consists of 2.4 GHz Intel Core 2 Quad, 4 GB RAM, GeForce 8800GTX. And, to my surprise, X-plane is slow on that and the textures aren’t as good as they could be (and it seems like only half of the 768 MB memory of the GPU is being used which is underutilizing available resources). We are very likely to keep the machine up to date, and GeForce 9000-series will follow the current 8800GTX, and the next card is going to have more likely more than 1GB of video ram.

There are two issues, with the 32 bit Linux kernel, the Linux also seems to see only 3 GB. Which is a pity, 1 GB is not in use. But no 64 bit kernel for us until X-plane gets upgraded to 64 bits.

The second thing is that it is a stupid thing that there are two cores out of 4 going idle when X-plane is slowing down with utilizing only two cores. X-plane should, in addition to having 64-bit version, agressively use thread-pools for calculating the geometry to become faster on multicore machines (we have even sometimes planned 8 Core Mac, until we realized, that X-plane actually only uses two cores). The simplest thing would be to increase the accuracy of the aero model by having multiple threads running it, so e.g. 2 remaining cores would each calculate one aero model per one frame.

So yes please, do a version for high end machines, with lots of ram, fast capable GPUs and lots of memory. Hardware is relatively cheap these days. I would rather use a more realistic looking & feeling sim.

And thanks for making such nice sim that runs on our favorite operating system (Linux) in addition to the 2nd favorite (MacOSX). We are using the sim on Ubuntu Feisty and will surely update it to 64 bit right away once you make the 64-bit version of the X-plane.

Best Regards,
Karoliina Salminen

Windows has similar APIs…serious database engines might use them in their low level pager.

I’ve looked at them, but my gut feeling is that the amount of work to modify our scene graph to allow pieces to be paged out of virtual address space (even if not out of physical RAM) is complex enough that it’s just as difficult as making the load of scenery more fine-grained, which is another way to address the problem.

I would hope that mapping physical RAM into the address space is a lot faster than loading scenery, but then loading scenery in smaller chunks helps even users with only 1 GB of RAM or less.

Another hitch: at higher rendering settings, a pretty good chunk of address space is being managed by the video driver to store all of the “driver objects” we create (that’d be buffers of geometry and textures). So if you have a 512 MB vid card and run on extreme res, 512 MB of virtual address space is being used to back up textures. I’ve seen geometry buffers easily break 250 MB on even modest settings.

The issue here is that since they’re under driver control, we can’t actually move them out of the address space – we can only choose to not build up the 3-d geometry in the first place (more incremental load). We’ve used incremental load in the past to save memory – back in X-Plane 830 or so, all of the roads in the area were built in 3-d no matter how far away..then in 840 we changed the rendering engine to build only what’s nearby, nuking geometry and building new stuff as you fly. This cuts down memory usage.

Given Microsoft’s policy of productizing the 32-bit vs 64-bit OS separately, and the whole batch of nice fast Intel core chips that are only 32-bit, I think it’ll be a while before the PC games world starts going 64-bit crazy.

Going 64-bit isn’t actually that hard for us from a programming standpoint – Joshua got the Linux version limping in 64-bit once without too much effort. It’s really more of a support issue of having even more versions of the sim floating around (4 or 6 instead of 2 or 3), less test coverage, more strange cases, more support workload, etc. That all takes away from coding features too.

I am sure 64-bit will happen some day…but it’s not high on my priority list. (Using more cores more completely is on my high priority list!)

Cheers!