Category: Hardware

64-Bit: Time Frames and Performance

First, for the plugin authors: I am hoping to start a 10.20 beta for 64-bit in weeks, not months.  I don’t know how many weeks it will be – there’s a huge potential for variation, but if you maintain a plugin, be aware that you’ll be able to actually test your plugin against a 64-bit X-Plane this year.

At this point we have launched X-Plane, 64-bit-style on all three operating systems.  That doesn’t make it beta-ready but we have a heartbeat.

X-Plane 10.10 is final, and we may cut a small bug-fix patch (10.11) before we go into 64-bit.  We have a handful of lower-priority bug fixes that we kept out of 10.10 for stability that we need to release at some point; the plan hasn’t been finalized.

Mac and 64-Bit: Not That Fast

So once I had a 64-bit X-Plane running on my machine, I did the obvious thing: crank the settings through the roof and see what happens.  And I can now report the results:

Very low framerate.

The problem is: my machine was very close to maxed out with 32-bits.  When I was able to crank the settings beyond where I could before, I simply overloaded it.  Too many objects, too many textures, too many vertices, too much stuff.  It’s a 2008 Mac Pro with a 4870 – not a spring chicken.

I mention this now because:

  • The overwhelming majority of users telling us they want 64 bits are Mac users.  On 64-bit Windows OSes, X-Plane has significantly more address space headroom, so you have to push the sim a lot farther to run out of memory.
  • Macs just aren’t that fast.  You either have a laptop (highly constrained by the need to be power-efficient) or an iMac (power constraints and no update for over a year) or a Mac Pro (with the best graphics card two generations old and no real CPU update in a while).

In other words, my Mac may be older and slower, but the very fastest ones aren’t that fast.  There is no Mac equivalent right now to an Ivy Bridge i5 or i7 with a GeForce 680.

So while you may be hitting address space limits and crashing on your Mac right now, you may not have that much hardware budget left over, and it may be a short trip from 64-bits to finding you’ve simply maxed out your hardware.

It’s All About the Watts

One last thought on Macs falling behind Windows gaming machines: while this used to be a function of technology it’s really become a race with only two factors: watts and time.

  • The older a model gets, the farther behind the curve it is. So the Mac Pro is really behind due to being age constrained; if they update it with a current-gen desktop GPU and an Ivy-Bridge based Xeon CPU it won’t be cheap, but it will be competitive.  For desktops the big issue is one of cost: you can get the latest mobo at any time for Windows and a game machine is significantly less than a Mac Pro.
  • Watts: how much GPU power you get is a function of the power budget of the card, and both the iMac and laptops are constrained relative to desktop machines.  The new Retina-Book MacBook Pros are nice, new, top of the line laptops, but they are also using the GeForce 650M, a decision to trade off some GPU power for battery life, heat dissipation, etc.  There will inevitably be an AlienWare laptop that ways 12 lbs, burns through its battery in five minutes, but ships with a bigger mobile GPU for better performance.  I’d rather use the lighter laptop, but my concern is traveling with my work, not flying.

My point here is: these two factors (revision time for models and power use profile) are unlikely to change any time soon – they are fundamental to Apple’s business model.  So Mac users, on average you are never going to have the same performance options as your Windows brethren.

Posted in Development, Hardware by | 36 Comments

Linux Joystick Permissions

Edit: see the end of the article for a GUI tool to manage joystick permissions.

I’ve already briefly discussed some of the changes necessary to get joystick devices working properly but I thought it’d be a good idea to consolidate all information into one post for easy reference as 10.10 is nearing it’s release to the masses.

First, why the change? In the past we used the “joystick” interface to joystick devices on Linux. This interface is extremely basic and is really only useful to games that require minimal knowledge of the actual hardware. X-Plane really does not fit this specification at all. X-Plane needs to work with the spectrum of hardware from the most basic one axis trim wheel to the most complicated home-built cockpits that have dozens of axis and literally hundreds of buttons and switches. In order to support this properly, in 10.10 we’ve switched from using the “joystick” interface to using the “input” interface. This gives us ALMOST the same quality of low level access to the hardware that we get on Win/Mac. The problem with using the “input” interface is that almost anything can be an input. Your keyboard and mouse for example are “inputs”. As linux is a multi-user operating system, there are permissions concerns regarding input device reading. You wouldn’t want another user snooping on your keyboard as you’re typing credit card numbers would you? Many Linux distros by default restrict access to these devices with some exceptions handled in ACLs. If the device LOOKS like a joystick, anyone’s allowed to access it since the security risk associated with joysticks are pretty much zero. But the definition of a joystick is something that has two axis and some buttons. Therein lies the problem. Rudder pedals don’t have any buttons. Trim wheels don’t have any buttons either and they only have one axis. Because of this, the ACL for the devices does not kick in and you now need root access to read from the device.

The solution…run X-Plane as root! I’m joking though some people will have no problem doing this. If you’re cool with that, be my guest but it’s generally not regarded as a safe way to run a system. For the rest of the population, there are rules than can be created that will detect your hardware and automatically set the permissions appropriately so that X-Plane can access the hardware. These are called UDEV rules. For a typical Linux user, creating a UDEV rule should be walk in the park but for a novice it might seem tricky. Luckily, it only needs to be done once and will work for good.

A big thank you goes out to Bill Good who is a member of the community. He put together this tutorial for you guys to benefit from.

  1. This is an optional step but it really makes things easier. Each piece of hardware has a Vendor ID and a Product ID. These are called the VID and PID in industry. These two ID’s together are used to detect a device’s existence. You’ll need to know the VID and PID of each device that you care about. To determine this, you can get a tool called “lsinput” which makes this a bit easier. Just run “sudo apt-get install input-utils” on a debian based system. If you’re Red Hat based, i’m sure you can run the similar “YUM” command.
  2. Run “sudo lsinput” which will list all /dev/input/event ‘s that are attached to the system. Find the hardware that you care about. Here’s a sample output for  a Saitek Pro Flight Rudder. Notice the Vendor and Product lines which have hex values of 6A3 and 763 respectively. That’s what we need.
       bustype : BUS_USB
       vendor  : 0x6a3
       product : 0x763
       version : 273
       name    : "Saitek Saitek Pro Flight Rudder "
       phys    : "usb-0000:00:16.2-4.1/input0"
       uniq    : ""
       bits ev : EV_SYN EV_ABS
  3. Create a file called “99-X-Plane_10_Joystick.rules” in your /lib/udev/rules.d/ directory. I’m not sure if this path is distro specific. You may need to look up where udev rules go on your distro. EDIT: Users report that a more appropriate path may be “/etc/udev/rules.d/” which has the added benefit of being a location that gets grabbed by backups. Either path will work fine however.
  4. In the 99-X-Plane_10_Joystick.rules file, create one entry for each device that you wish to include. Put them all in this file…each hardware entry on its own line. Only the ATTRS sections need to be set by you, the rest is boilerplate. Notice the Vendor and Product values of 6A3 and 763 from before in the sample below (Make sure to scroll horizontally. On smaller monitors, the whole string may not be visible).
    KERNEL=="event*", ATTRS{idProduct}=="0763", ATTRS{idVendor}=="06a3", MODE="0666"
  5. The last step requires a restart of the system. There MAY be a subsystem that can be restarted instead of taking the whole system down but i’m not aware of what that may be so it’s best to just restart the whole thing.

Update: One enterprising Linux X-Plane user has written an open source GUI tool to manage joystick permissions.  Here it is!


Posted in Hardware by | 13 Comments

CSI: Joystick Edition

[Scene opens with a joystick being thrown across the room in frustration. Camera angle is from the ceiling looking down. A rotating and twisting view creates tension as it centers on the joystick, laying abandoned on its side as the dust settles. Cut away to a different angle. In the background is an iMac with Google Chrome open in the background just barely in focus.]
[In walks developer Chris Serio wearing a pair of Ray-Ban sunglasses. He nudges the joystick with his boot before crouching down and removing his sunglasses to get a closer look.]

Chris: “Looks like someone really had it out for this Joystick”
Ben: “Yeap…tossed it like a salad at Denny’s. What do you think ticked them off?”
Chris: “I bet Google’s behind this somehow…”
Ben: “Google? Really? I thought their motto was to do no harm?”
Chris: “On the contratry…They’re involved in everything!”
[Chris stands up and walks over to the computer…the camera zooms in as Google Chrome comes into focus on the screen]
Chris: “You see this? Chrome…that’s not a coincidence. I want the computer’s ip address…run it through CODIS. Bag it and tag it”
[The camera moves back and zooms out as Chris pulls his sunglasses from his pocket, placing them on his face as he pauses to speak]
Chris: “This Joystick killer’s about to get…..yoked”
[Cut to opening credits as The Who’s “Won’t Get Fooled Again” plays loudly]

Ok so perhaps I’ve seen too many episodes of CSI in my time…but sometimes I must say I do feel like more of a detective than a developer.

The latest weirdness with joysticks is that on Mac only, sometimes they do not seem to work at all. In the log, you’ll see an error message stating that the device could not be opened. I’ve seen it myself before and it’s odd because typically device access is shared between processes. Imagine if your keyboard only worked in your word processor because it demanded exclusive access and none of the other applications on your computer could use it once the word processor was opened. That’d be silly right?

I started killing processes on my system one at a time until the joystick finally started working again. Killing Google Chrome is what did it. Why on earth would a web browser be touching my Joystick hardware?!

After a bit of research and a run through Chrome’s source code (isn’t open source great?), I discovered a new system in HTML5 compliant browsers like Chrome called Gamepad. Gamepad allows new HTML5 pages to access your joystick hardware! Because of the Olympics, the daily Google Doodles have been little mini games which are stealing Joystick access! So Olympics + HTML5 kills Joysticks in X-Plane….amazing.

The solution is a simple change for them. They just need to pass a different flag so that they share the device with other applications. I’ve already filed a bug and spoken with the developer and the fix will likely be in Version 22 of Chrome but for now, make sure your browsers are closed if you appear to be having intermittent Joystick issues on Mac.

Sometimes reality is stranger than fiction…

***EDIT*** I do have to say, I got an immediate response from the engineer in charge of this Chrome feature and within an hour the bug was fixed and checked in for release in future versions. I can’t ask for better support than that.

Posted in Development, Hardware by | 13 Comments

Still having joystick trouble?

As you are hopefully already aware, the Joystick subsystem of X-Plane was completely rewritten for X-Plane 10.10. It uses a much lower-level method of communication to essentially talk directly to the devices so that we have complete access to their capabilities instead of being limited to what a “middleman” layer of software feels like telling us…which is how things used to work.

While most of the bugs have been fixed as of 10.10Beta 4, there still remain a small subset of devices that are still having problems. Let me list the known open issues:

  1. Even after calibration, some devices still show their axis max limited to about 75% of what it should be when viewed on the Axis tab of the Joystick Dialog. In other words, pull the yoke toward you and it goes to 0, push the yoke away from you and it goes to 75% instead of 100%. This is not a joystick bug at all but in fact a UI bug that’s been around all along but just never visible until now. This has been fixed in 10.10Beta 5 which is coming soon. You can also go to the “Null Zone” tab and see that your axis does in fact have it’s full range of travel.
  2. Some hardware does not appear at all on Linux. This is not a bug! This is a security feature of the Linux operating system. The problem is, Linux is a multi-user operating system and it has to worry about permissions to devices that are attached to the system. Take a keyboard for example…imagine if another user logged in could see everything you were typing because he had read permissions on your device! Linux locks down permissions on devices that are not part of an exception. The way to create an exception is to create a UDEV rule. If you don’t know how to write a UDEV rule, google it a bit..they are not very complicated for the average linux user. If you’ve chosen linux as your operating system, we hope you possess the skills to configure it. Here’s a simple sample rule:
    KERNEL=="event*", ATTRS{idProduct}=="0bd4", ATTRS{idVendor}=="06a3", MODE="0666"

    Here the VID is 0x06A3 and the PID is 0x0BD4. These are unique codes that identify that brand/model of joystick and the rule says “When you see this device, chmod 666 it.” One way of finding your VID/PID is by doing “lsusb -n”.

  3. Some devices have hat-switches that appear to “stick” in the ON position. This is fixed in 10.10Beta 5 as well.
  4. Last but not least, there are some devices that have particular AXIS or HAT SWITCHES that simply do not work. So far, I’ve seen a Logitech G25 clutch pedal and a Logitech G940 hat switch that doesn’t work. It works in the windows calibration screen as well as X-Plane 10.05R1 but not in the latest version.

Here’s where you guys come in. If you have one of those two Logitech devices, please let me know if yours is working just fine or if you have the problem as well.

I’m also interested in hearing about other devices that are having the #4 issue as well.

Lastly, if you are having any other kinds of Joystick problems that do NOT exist in 10.05R1 but that DO exist in 10.10 that haven’t already been mentioned, please let me know.

You can file a bug and please include a Log.txt file from 10.10Beta 4 as well as a description of what’s not working properly and on which device.

Posted in Hardware by | 7 Comments

X-Plane 10.10 Beta 3: Rapidly Beating HID Into Submission

X-Plane 10.10 Beta 3 is here.  To avoid having to type it each time, all of the info about betas is now on the release notes page here.  Please read it carefully!  Please: no bug reports on the blog, only on the bug report form!

You may have noticed the large number of joystick-related bugs in X-plane 10.10, something that is unusual for X-Plane betas.  There is a reason for this: Chris totally rewrote the joystick IO code from the ground up for 10.10.  We had been living on the same old dubious code for perhaps 5 years before; the new stuff is literally brand new.

Chris is working through the joystick bugs at a pretty quick pace.  We will continue to push betas frequently as long as there are bugs that interfere with us collecting other bug data (e.g. crashes, joysticks totally inop, etc.); then we’ll slow the pace of betas down to get more fixes in per beta.

What possessed us to send Chris off into HID land on a quest for new IO code?  The new IO code is meant to support a number of features, a few in 10.10 but most coming in a future build:

  • Hot swapping (here now).
  • Correct hat switch operations (here now).
  • Preferences bound to more than one stick without resetting (here now).
  • Automatic configuration (coming in the future).
  • Better descriptions of the hardware in the UI (coming in the future).
  • Ability to easily open source the Linux IO code (coming in the future).

The new code sets up a unified interface to the hardware, with the hope of sharing configuration info and being able to open source the low level IO code.

The long term goal is to make it really easy to work with X-Plane joysticks: plug it in, go through the absolute minimum configuration just once, and you’re flying.

What, You’re Not Root???

Linux nerds: X-Plane 10.10 moves from the joystick API to the input API for joystick IO.* The input API gives us a modern interface with better meta data about the hardware.  However we have seen cases where the access control list on the “event” device for the joystick isn’t user-readable even when the “joystick” device is.

Chris is still discussing what we can be done with knowledgeable Linux types, but my view is: this seems like a bug.  If the device is safe for users as a joystick, it’s safe as an input event source, and it shouldn’t be necessary to make a udev rule and/or chmod the device entry to use the joystick-type device.  So perhaps at some point we can push corrected udev rules up into upstream distributions.

But this isn’t something that Chris and I have any expertise in; if you are a Linux X-Plane user and have expertise in the area, please keep an ear open for when we get closer to a resolution on this issue.

(In the meantime, you may have to take the sudo-hammer to your joystick in 10.10.)

* Our preferred interface would be a HID interface, but we don’t have our own HID descriptor parser; we use the OS X and Windows one.  There are two show-stoppers to speaking raw HID. One is the lack of a parser on Linux and one is that the raw HID-as-report device has similar permissions problems to the ones mentioned above for weird joysticks, except the permissions are root only all the time.

So some day in the future perhaps we’ll get to reading raw HID (which would give us perfect similarity to Mac/Win) but for the time being we expect to ship on the unified input interface.

***CHRIS’S EDIT*** I _think_ I’ve squashed all kinds of Joystick related crashes and Joystick calibration issues. These are issues where the stick would not move smoothly from one end of travel to the other. I also think I’ve squashed issues where certain devices/axis were just not showing up. If you have a device that’s still having problems with Beta 3…PLEASE FILE A BUG REPORT. I definitely want to know about it. Always include a Log.txt from a sim run that had the device attached.

Posted in Hardware, News by | 19 Comments

Linux and Hardware/OS Abstractions

This post will pretty much only be of interest to Linux users – everyone else, talk amongst yourselves.  Topic of discussion: is neither a plane nor a communist.  (Sorry, work on the road processing code has drained me of any remaining sanity.)

Linux History

The brief history of X-Plane for Linux is that Joshua Wise ported X-Plane to Linux a while ago because he felt like it (and being too young to drive at the time, apparently had some free time).  The Linux port was never a commercial effort. – Laminar Research didn’t say “we’ll make a ton of money by porting to Linux, so let’s hire someone”.  It just sort of happened.  (Well, I wasn’t in the room so I don’t know exactly what was said.)

Linux has steadily represented about 5% of our user base from that point on, and this gets to the “commercial problem” of Linux: even with the work we do to try to keep platform specific code in X-Plane to a minimum, Linux sales don’t justify the development cost to maintain the platform.

Yet there still is a Linux version of X-Plane.  We keep renewing the Linux port for “one more version” because while the Linux community doesn’t buy a ton of copies of X-Plane, Linux users do contribute in an outsized way by providing code back to the scenery tools and other development efforts.  In other words, the Linux community doesn’t contribute dollars, but they contribute a lot of code.

Code Contributions

This came up during the X-Plane 9 and 10 Linux discussions.  Our primary request to Linux users has been “please support each other”.  There are too many Linux distributions for us to provide support; our dedicated support staff does not even have Linux expertise, so Linux support immediately hits engineering.

While a number of Linux users have really done a great job of helping other users out, another issue came up.  One of the ways we try to minimize Linux-specific costs is to keep the OS-specific code very basic and rudimentary.  In the past we’ve taken patches from users to fix OS specific bugs, but this is an awkward process at best.

Some Linux users asked if we could find a way to release source to the OS-specific parts of X-Plane so that they could improve the Linux-specific code (and thus the platform-specific experience) themselves.  Right now this is a very awkward process: I have to tell the user “give me a snippet that does X” and then hope that I can get the snippet integrated and tested on my own.

One of the suggestions that came up at the time was to separate out some of the code that abstracts the OS/hardware so that Linux users could patch it more easily.

A Hard Abstraction

Separating out the platform specific code is a good idea, but it wasn’t one we were going to drop everything to pursue – if we did, the end result would be no improvement to X-Plane after some number of weeks of heavy development.  Instead, we are slowly moving the code in this direction as we work on it.

The first code to get a work-over is the joystick code; Chris has been refactoring the joystick code for a few weeks now.  10.10 won’t show you any new behavior; it runs the existing UI on top of new low level code.  Once we are sure this works, Chris can implement a bunch of new joystick UI features on top of the new low level code quite easily.

The new joystick code separates out the OS-specific joystick interface code from the rest of X-Plane.  In the long term, this will make it practical for us to share the hardware abstraction code with users as source, take patches, and even allow developers to swap it out on their local development machines via a shared object.  We’re not there yet with this level of flexibility, but the new code makes these things possible.

You Can Keep Your Hat On

There is one immediate win to the new code that will be apparent to Linux users in X-Plane 10.10: the new code (which is based on input.h instead of joystick.h) recognizes hat switches as a set of buttons, rather than a pair of axes; this is almost certainly better from a UI configuration standpoint.

Posted in Development, Hardware by | 35 Comments

Catalyst 12-3 Drivers Fix 7970 Artifacts

I meant to post this before, but: the new Catalyst 12-3 drivers fix a number of Radeon HD 7xxx-specific artifacts with X-Plane: incorrectly cut-out tree billboards and flashing triangles.  So while I suggest latest drivers anyway, this update is particularly useful if you have a 79xx.

Posted in Hardware, News by | 4 Comments

If Your Framerate Gets Slower Over Time, It Might Be the Cars

Just a quick tip on tuning X-Plane’s rendering performance: if you see your fps start off strong and then drop over time to a crawl, with low GPU, turn down the cars.

Here’s the problem: cars are spawned over time.  The way the car engine works is that X-Plane comes up with a budget for cars based on rendering settings, and adds a few more every frame as long as it’s under budget; if it is over budget it simply doesn’t replace cars that are killed by being too far from your plane or reaching a dead end.

It can easily take several minutes for car traffic to build up.

And the thing about the car traffic is: it’s incredibly CPU intensive.  This is something that I am working on and it may get better for future patches, but for now just consider this: a reasonable setting for cars (for your computer) should be based on the framerate after several minutes, not the one you instantly get when there are virtually no cars!

Posted in Development, Hardware by | 8 Comments

Clouds, Screws, and Settings

I’m listening to Marco Arment and Dan Benjamin debate whether a user setting could have avoided the incident where a man’s iPhone rang during a concert.  I also just finished reading the Steve Jobs biography.  It got me thinking about the trade-offs between a closed non-configurable system and an open, configurable one.  This comes up in an X-plane context every time we poke at the cloud rendering settings and someone asks whether we can put in more settings for additional configuration.  What trade-off is right for X-Plane?

Chris suggested an analogy to me a few weeks ago that I think is pretty good: tuning the rendering engine in X-Plane should be like tuning the timing in your car.  It should be possible, if you are a serious expert and enthusiast, to change the tuning (and if doing so wrecks your engine, well, you were asking for it by opening up the engine), but it shouldn’t be easy.  Regular users of the car expect the manufacturer to have a lot more expertise, and to set the timing to an optimal setting up front.

I think the same thing goes for X-Plane.  I should use as much expertise as I have to maximize efficiency no matter what trade-off is being made; at no point should dialing in a setting result in stupid behavior inside the engine.  It’s up to me to know what can be inefficient and avoid that happening.

So: the rendering settings are going to remain as simple as possible, and any time we can make them more simple, less likely to be set up wrong, or any time we can realign them to be better aligned with user constructs (“more houses”) instead of internal constructs (“higher instancing density ratio!”) we’ll take that win.  It should not be the user’s job to tune the engine, and any time that is necessary, that’s a failure by me to pre-tune the sim, not a feature.

I don’t think we are even close to the kind of rendering settings that are really useful to non-expert users; one of the frustrations with performance tuning over the last few months has been the number of times a user has sent me rendering settings and it was clear that the settings were inefficient for the given hardware.

The answer is not to try to make every user into an expert in the OpenGL pipeline; the answer is to change the settings so that users don’t have to be experts.  This is not easy to do; the reason it’s not done yet is that we will have to create new code and do real hard work to make the interface simple.  One theme that both Steve Jobs and Jonathan Ive describe when discussing their design philosophy is that, to make something simple in its final product, you have to dig down and master the complexity that you want to get rid of.  To make the rendering settings simple but still powerful, we are going to have to solve these performance-efficiency-hardware problems ourselves and encapsulate that knowledge in code, and that’s not trivial.

Underneath the settings are a whole pile of art controls, and if you really want to, you’re more than welcome to enter any value you want in there.  If you discover that you’re better at tuning the engine than I am, I will be very happy to hear what you did!

This attitude is not as extreme as the “Steve Jobs” approach; Apple devices often use custom screws to ensure that normal people can’t open their devices even if they want to.  We are hiding implementation out of sight, but we are not locking that implementation at all.  The settings file is plain text, the art controls are viewable with a publicy available plugin (DataRef Editor).

X-Plane has always been a hackable sim, and one of the things I used to enjoy back in X-Plane 6 was just looking at all the stuff in the resources folder; the raw textures were pretty amazing to view in themselves.

My goal here is not to take that away; only to make hacking and opening up the sim something you can opt into if you are curious, instead of something mandatory to get good performance.

Posted in Development, Hardware by | 24 Comments

Mobile GPUs and Fill Rate

Fill rate: when we talk about fill rate, generally what we’re talking about is your GPU’s ability to fill in individual pixels to make the final image you see while flying.  (The actual components of GPU throughput get a lot more complex, but we’ll keep things simple for now.)  Two key things to note about fill rate:

  1. It only comes from your GPU – not your CPU.
  2. The bigger the size of X-Plane’s window (or the higher the full screen monitor res), the more of it you use.

Therefore I can offer this very simple test as to whether you are fill-rate limited:

If you are running in windowed mode and making the window smaller improves frame-rate, you are fill-rate limited.

(There is actually one important exception to the above test: if you are running out of VRAM, making the window smaller uses less VRAM for the main window + off-screen buffers, which can help fps.  So be sure to see whether cutting your texture res helps fps – if it does, you are out of VRAM.)

Fill rate gets used up by:

  • A larger rendering window.  This is the number one consumer of fill-rate.  Double the size of the window in each dimension, you use 4x the fill-rate.  That adds up quick!!
  • Clouds tend to be fill-rate intensive.
  • HDR mode is significantly more fill-rate intensive than non-HDR mode.
  • The 3-d cockpit is more fill-rate intensive than 2-d and external views, particularly with HDR enabled.
  • Shadows, to a limited extent.

X-Plane 10 contains a stat called “cpu load” in the framerate output data line; I will describe its full meaning and implication in another blog post, but generally low CPU load (e.g. < 0.7) means you are fill-rate limited.  If your CPU use for one core is 100% (this means 25% in the task manager for Windows users on a 4-core i5, but 100% in top for Mac/Linux users no matter what the number of cores) then you are almost certainly not fill-rate limited.

Optimizing Fill Rate

X-Plane 10.03r1 will post in a little bit – this is our first attempt to finalize X-Plane 10.03.  It is not the end of the bug fix and performance tuning work for X-Plane 10.  But if we can get a stable 10.03 we can use it as a baseline and limit betas to those who check the “get betas” check-box in the installer.

X-Plane 10.03r1 contains fill-rate optimizations for the 2-d and forward-no-HUD views; we’ll have to see how much they help people, but they should help you a bit if you are fill rate limited, flying a plane with a 2-d cockpit, and are seeing low fps with clouds and/or HDR.

Once 10.03 is final, we’ll start 10.04 and I will attempt to make a similar set of optimizations for the 3-d cockpit.  Note that the 2-d optimizations do not apply if you have a plane that uses the 3-d cockpit for the 2-d view.  (Since all of the new X-Plane 10 default planes do this, we’ll need the 3-d optimizations in 10.04 to see the performance benefit with the 747, Baron, and other new default planes.  The Cessna, Cirrus Jet, and Piaggio from X-Plane 9 should all benefit immediately.)

Your Mobile GPU Is Light But Not Fast

Here is a table I culled from Wikipedia: it is a table of GPU performance for the “top end” cards for ATI’s last 4 generations of hardware.

4870Jun 0812301151200
6970MJan 1121321151305
5870Sep 0927681532720
6970Dec 1028841762703
7970Jan 12291182643789

GP = gigapixels/second of fill, GT = gigatexels/second of texture, BW = GB/second of memory bus bandwidht, and GFLOPS = gigaflops/second of MADD.  At least I hope – see the original table.

Now I have inserted one mobile GPU (the 6970M) into this chart.  So the first thing you can see is: the 6970M provides in a laptop the power that was available in a desktop about two years earlier, more or less.  That’s a big step back in time.

The reason is simple: mobile GPUs are typically cut down in their core configuration – there’s no way you can run a 150W full power GPU with those 3 fans in a laptop.

If you have an iMac, you have a mobile GPU.  Even the older iMacs which didn’t have the “M” designation on their chip, those were mobile too.  In fact, you’ve got a mobile GPU on a huge screen.  (Super-size to the 27″ iMac to get the 4x fill rate boost and you pick up 1.7x the pixels; if you get the big iMac with the cheap GPU you have a mid-range mobile GPU on a 2560 x 1440 screen!)

Some Kind Of Summary

I’m not entirely sure what my main point here is…perhaps the executive summary is:

  • We (LR) are working to optimize fill rate in X-Plane 10.  Fill rate is not the only performance bottleneck we are working on, but it is a very important one.  Some of this is in X-Plane 10.03r1, some will come in later updates.
  • You can determine whether you are fill-rate limited by resizing your window.
  • If you have a mobile GPU in a laptop or iMac you may have less fill rate than you would expect.
Posted in Development, Hardware by | 53 Comments