We’ve received a number of reports over the last month of X-Plane hanging on startup with NVidia graphics cards on Windows. Most users don’t see this, but some do. We fixed one use of off-screen rendering in X-Plane 9.67 and this fixed some of the users with hung video cards but not all.
I am working with the remaining users now; my hope is that we’ll find something we can change in X-Plane to work around the problem. I don’t believe that the code in X-Plane 9.62 was actually incorrect, but it was simple enough to change.
I have also read some posts regarding poor performance on the GeForce 400 series (Fermi cards) vs. the older 200 series. I have no hard data on this, and frankly, a lot of the discussion on the net strikes me as completely speculative.
Fortunately alpilotx has a GeForce 500 series card on order, and he is working with me on next-generation DSF renders for X-Plane 10. From my perspective, the big question about the GeForce 400-500 series (Fermi and beyond) is: how well do they implement the DirectX 11/OpenGL 4.0 feature set? In particular, X-Plane 10 is going to make heavy use of full hardware instancing, and while this has been available on ATI cards since their HD2000 series, the implementation has been partly in software on NVidia DirectX 10 cards.
The question our users want to know is: if I have a preference for NVidia, can I get a DX11-class NV card for X-Plane, or should I move to ATI. By looking at instancing performance, perhaps we can determine if these cards are contenders.
(I am not worried about overall “how many fps” do you get because y’all can measure that now with X-Plane 9.)
Edit: since a number of you have jumped in with performance reports: please post the following performance info in your replies:
- Precise graphics card
- CPU with clock speed
- Results of –fps_test=3 (3 phases) with X-Plane 9.67.
If you have a DirectX 10 or 11 class video card (that is, a GeForce 8nnn or newer or a Radeon HD card) and you’re on a Mac, consider updating to OS X 10.6.x if you’re still on OS X 10.5.8.
10.6 has performance enhancements in the video drivers that I suspect will benefit X-Plane 9 users, but it will really matter for X-Plane 10. We need OS X 10.6 to expose some of the OpenGL extensions that these cards have. Thus 10.6 will get you faster frame-rate, more realistic lighting, and more efficient VRAM use.
(If you have an older card, I don’t know if you’ll get any benefit, although I doubt you’ll see a performance loss.)
I’m never thrilled about posting bug-swatting info on this blog; the blog is (among other things) a temporal snapshot of what’s going on in X-Plane, as well as an archive; it’s my hope that we’ll get this problem sorted out soon, at which point this blog post will do nothing but confuse. But I digress.
There have been a number of reports from users of the sim hanging on startup with this configuration:
- A 64-bit Windows (usually Vista or 7).
- A modern ATI card running Catalyst 10-6 or 10-7 drivers.
- X-Plane 9.62rc2.
- Usually a core i7 type system.
However, I haven’t been able to reproduce this, and neither has ATI.
I don’t know what the problem is, but a number of variables have changed in this equation that need to be isolated: new sim, new video drivers, newer operating systems.
So if you have this configuration and can’t run the sim, despite removing all third party add-ons, please download this time demo. If you can run the 945 time demo but cannot run 962, please let me know by email, and we’ll isolate a defect in the sim. I have heard from some users that they can run 940, but no confirmation that 945 runs.
This isn’t supposed to be a coding blog, but users do ask about DirectX vs. OpenGL, or sometimes start fights in the forums about which is better (and yes, my dad can beat up your dad!). In past posts I have tried to explain the relationship between OpenGL and DirectX and the effect of OpenGL versions on X-Plane.
At the Game Developers Conference 2010 OpenGL 4.0 was announced, and it looks to me like the released the OpenGL 3.3 specs at almost exactly the same time. So…is there anything interesting here?
A Quick Response
In understanding OpenGL 4.0, let’s keep in mind how OpenGL works: OpenGL gains new capabilities by extensions. This is like a new item appearing on a menu at your favorite restaurant. Today we have two new specials: pickles in cream sauce, and fried potatoes. Fortunately, you don’t have to order everything on the menu.
So what is OpenGL 4.0? It’s a collection of extensions: if an implementation has all of them it can call itself 4.0. An application might not care. If we only want 2 of the 4 extensions, we’re just going to look for those 2 extensions, not sweat what “version number” we have.
Now go back to OpenGL 3.0, and DirectX 10. When DX10 and the GeForce 8800 came out, nVidia published a series of OpenGL extensions that allowed OpenGL applications to use “cool DirectX 10 tricks”. The problem was: the extensions were all NVidia specific tricks. After a fairly long time, OpenGL’s architectural review board (ARB) picked up the specs, and eventually most of them made it into OpenGL 3.0 and 3.1. The process was very slow and very drawn out, with some of these “cool DirectX 10 tricks” only making it into “official” OpenGL now.
If there were OpenGL extensions for DirectX 10, who cares that the ARB was so slow to adopt these standards proposed by NVidia? Well, I do. If NVidia proposes an extension and then ATI proposes a different extension and the ARB doesn’t come up with a unified official extension, then application like X-Plane have to have different code for different video cards. Our work-load doubles, and we can only put in half as many new cool features. Applications like X-Plane depend on unity among the vendors, via the ARB making “official” extensions.
So the most interesting thing about OpenGL 4.0 is how quickly they* made official ARB extensions for OpenGL that match DirectX 11’s capabilities. (NVidia hasn’t even managed to ship a DirectX 11 card yet, ATI’s HD5000 series has only been out for a few months, and OpenGL already has a spec.) OpenGL 4.0 exposes pretty much everything that is interesting in DirectX 11. By having official ARB extensions, developers like Laminar Research now know how we will take advantage of these new cards as we plan new features.
Things I Like
So are any of the new OpenGL 3.3 and 4.0 capabilities interesting? Well, there are three I like:
-
Dual-source blending. It is way beyond this blog to explain what this is or why anyone would care, and it won’t show up as a new OBJ ATTRibute or anything. But this extension does make it possible to optimize some bottlenecks in the internal rendering engine.
-
Instancing. Instancing is the ability to draw a mesh more than one time (with slight variants in each copy) with only one instruction to the graphics card. Since many games (like X-Plane) are limited in their ability to use the CPU to talk to the graphics card (we are “CPU bound” when rendering) the ability to ask for more work with fewer requests is a huge win.
There are a number of different ways to program “instancing” with OpenGL, but this particular extension is the one we prefer. It is not available on NVidia cards right now. So it’s nice to see it make it into the core spec – this is a signal that this particular draw path is considered important and will get attention.
-
The biggest feature in OpenGL 4.0 (and DirectX 11) is tessellation. Tessellation is the ability for the graphics card to turn a crude mesh with a few triangles into a detailed mesh with lots of triangles. You can see ATI demoing this capability here.
There are a lot of other extensions that make up OpenGL 3.3 and 4.0 but those are the big three for us.
* who is “they ” for OpenGL? Well, it’s the architectural review board (ARB) and the Khronos group, but in practice these groups are made up of employees from NVidia, ATI, Apple, Intel, and other companies, so it’s really a collective of people involved in OpenGL use. There’s a lot of input from hardware vendors, but if you read the OpenGL extensions, you’ll sometimes see game development studios get involved; Transgaming and Blizzard show up every now and then.
One last comment about driver crashes: I try to be fair about the distinction between causation and correlation when it comes to driver bugs; the piece of software that “fixes” a bug may not be the piece of software that contains a bug, and work-arounds happen in both directions between drivers and apps.
Similarly, seeing “ATI” or “NVOGL” in your crash report does not imply a driver bug. It does imply that the crash happened in the driver, but the driver crash may be a proximate cause, while the ultimate cause may be in X-Plane. (Sometimes the stack crawl is also just plain wrong, depending on the severity of the crash.)
OpenGL drivers need to be very, very fast; the whole point of buying that shiny new GPU was to get faster framerates. So driver writers have to make trade-offs about how much error checking they do when an application passes in junk data. If I were writing a driver and debating an error check that would slow performance and prevent a crash of an application that passed illegal data (but not the machine), I might very well skip the error check and say “if the application doesn’t want to crash, it should pass better data.”
Of course, it’s not up to me, and it’s not always up to the driver writers; the OpenGL specification actually dictates what outcome are acceptable in various error conditions. Quite often, “program termination” (read: the application crashes but the machine does not) is an allowed response to certain kinds of bad data from the application to the driver, particularly where checking the data would slow performance for all applications and the application should know better.
My friends say I have become a technological curmudgeon…whenever a new gadget or device or operating system comes out, I just grumble about how that it just means more bugs and mutter about how a byte only had 7 bits when I was young.
How did this happen? Pretty simple. New driver comes out, new bugs and interactions with X-Plane, rinse, wash, repeat. This is not a criticism of the driver writers. Those guys have an impossible job: write code that is super high performance in an environment that is highly unforgiving (an X-Plane crashes X-Plane; a video driver bug crashes your entire machine), then do it again when the next hardware comes out 9 months later. As the apps guy integrating on top of this ever-running treadmill of new hardware and drivers (think I Love Lucy) I sometimes dream of a week when none of the software that X-Plane runs on top of changes.
This is not one of those weeks. Snow Leopard came out, and it looks like Apple has been quite successful in keeping the price low; I’m seeing plenty of bug reports against 10.6 and it’s only been a few days. Apple ships video drivers with the OS, so Snow Leopard isn’t just a new OS, it’s new drivers too, as well as possible changes to the OpenGL “middle” layer that Apple provides.
Now about my pants…over the last few years I have been accumulating graphics card + operating system combinations, so I can see a higher percentage of hardware-related bugs “in the lab”.* But my wife and I are in the process of relocating to Boston, and this has temporarily separated me from a significant subset of my hardware. The result: driver bugs are coming in and I can’t easily reproduce them.
To paraphrase Airplane, I picked the wrong week to quit sniffing OS betas.
(I know I’ll take some slack for this, but: why did you all go and grab an OS update so fast? What have you gained? The down-side is lost time and application compatibility problems…was it worth it?)
*Just because it’s hardware related doesn’t mean it’s a driver bug – X-Plane can be the broken app too! Sometimes drivers work around X-Plane bugs and sometimes X-Plane works around driver bugs. I mention this because plenty of apps developers complain on forums about “driver bugs” – but how many of them repost when they discover a null ptr in their code? A driver and an app are two pieces of software that have to be integrated, and bugs crop up on both sides.
A number of users have confirmed that the new ATI Catalyst 9-1 drivers fix the artifacts introduced with the 8-12 drivers! No need to stay back on the 8-11 drivers any more.
It’s nice to have this bug fixed – long time X-Plane users saw this as soon as they updated from 8-11 to 8-12 – they updated drivers and the sim got weird looking, so they just rolled their drivers back.
But a number of MSFS users have tried the X-Plane demo for the first time using 8-12 drivers and wondered how we could ship such a lousy product. The key, of course, is that MSFS uses DirectX drivers, while X-Plane uses OpenGL drivers, so the 8-12 drivers affected X-Plane but not MSFS.
I’ve been poking at the FRAMEBUFFER_INCOMPLETE messages that some people get. The best I have so far is: run with –no_fbos and –no_glsl (learn how
here). If you get this card and you have 2 GB of RAM, consider turning your rendering settings down a bit.
And 930? I got my last beta stopper fixed today, so it’s time for a scotch! I’ll post more on the beta tomorrow.
For those who posted comments, sorry it took so long to moderate them – for some reason my spam filter decided that notifications of comments are, well, spam, so I just found them now. I should have known people would have jumped into a Vista-bashing thread. 🙂
There is an X-Plane 9.02 beta 1 posted – like 901 we’ve been pretty quiet about this, but you can get it by enabling “get betas” and running the X-Plane updater. Please give it a try. Like 901 it is a small change for the purpose of localization, but it actually has an interesting feature pair:
- True-type fonts and
- Unicode-aware.
This is part of some rework we did to provide better language support. So…you should be able to run X-Plane no matter what weird characters* are in your folder names, name your airplanes funny things, and see diacritical marks. 902 uses a font that provides all of the Latin and Greek/Cyrillic code pages.
Also I have heard reports of improvements based on drivers:
- nVidia has 175.16 drivers out and they apparently address “stuttering” issues. The stuttering issue has been on my list to investigate because it happens under Windows but not Linux. If you have stuttering performance on high-end NV hardware, particularly with forests and Windows, please try 175.16 and let me know how it goes.
- ATI has released Catalyst 8-5. Catalyst 8-3 and 8-4 were causing “incomplete framebuffer” errors for some users, but I was unable to reproduce it (after spending a good day trying to jam Windows XP onto an iMac already crammed with Windows and Linux….yet another episode of a Tale of Three Operating Sytstems). Anyway, at least one user reported the issue as fixed in Cat 8-5, so if you are having problems, please try the new driver set.
As always, bugs in the X-Plane beta should go to our bug report form, on the X-Plane contacts page.
* You might accuse me of being American-centric in decrying diacritical and greek letters weird – but the truth is I am computer-centric…anything that is not in the original ASCII set is weird. 🙂
