TL;DR version: we’re not dropping any operating systems; we may add one or more new APIs while continuing to support OpenGL in the future. The new APIs are similar to each other in design.
About two minutes after WWDC announced that Metal (Apple’s new low-level high performance 3-d graphics API) is coming to OS X, I received a bunch of questions about whether we would support it, and what this means for X-Plane. Now that I’ve had time to watch the WWDC Metal videos (and read the Direct3D 12 preliminary documentation and the Mantle programming guide and watch the Vulkan introductory talk) I’ll try to clarify a little bit about Metal, Mantle, Vulkan, Direct3D 12, and what we might do with them someday.
So Many APIs, So Little Time
Recently there has been an explosion of new graphics APIs. Here’s the list. It’s long, so get coffee first:
- Metal is Apple’s new 3-d graphics API; it shipped on iOS last year and will run on the next major release of OS X. Metal’s API is actually objective C, which means you’re almost certainly not going to see it on a non-Apple platform. Metal runs on iOS devices with an A7 chip or newer; I don’t know what GPUs OS X 10.11 will support.
- Mantle is AMD’s low level 3-d graphics API. I don’t know what kind of weird state it’s in; drivers have been available for a while and there are shipping games using it, but it’s still a beta or something. Mantle is AMD and Windows specific (but could be ported in theory), and requires a GCN architecture GPU or newer (e.g. a Radeon HD 7nnnn or the new RX290s.)
- Direct3D 12 is the next version of Direct3D, coming out with Windows 10. I think it’s in beta right now. It is Windows only and I think will run on a mix of DirectX 11 and 12 hardware. (This isn’t that different from Mantle.) I think Direct3D 12 will be available for the X-Box One in the future, but I didn’t investigate consoles carefully.
- Vulkan is a proposed new cross-platform open low level API from Khronos, the group that manages the OpenGL spec. Vulkan’s rough design goals were announced a few months ago, in a joint announcement that featured developers from AMD, Intel, NVidia, Qualcomm, ARM, and Imagination – that is, almost the entire set of GPU vendors from the mobile and desktop space. AMD is apparently letting Khronos use Mantle as a starting point, and most of the sample code shown as Vulkan looks like Mantle code with the prefixes renamed from gr to vk. Vulkan would potentially run on Windows, Linux, and Android – it is the only candidate next-gen API for Android. So far Apple has said nothing about Vulkan support that I am aware of. Vulkan is thus simultaneously both the logical successor to OpenGL and the least developed of the four APIs. (The other three are either shipping or in beta.)
It should be noted that we care about all of the operating systems mentioned above:
- We are working on the Android port of X-Plane 10 Mobile now, so we care about iOS and Android for the mobile space.
- On desktop, Windows is our majority platform – last I checked we were at least 65% Windows, and this number has been growing. Windows is also the most heavily used OS where a user can build a true “gaming” machine (that is, a machine that uses a lot of watts to generate a lot of compute power), so having good graphics on Windows really matters.
- We are not dropping OS X – it’s still a significant platform, and as long as people want to fly X-Plane on OS X, we’ll let them. Mac hardware doesn’t really qualify as gaming hardware – every current Mac is a power-constrained by the standards of core gamers, but the machines are also not slow either – Apple makes viable machines for flight simulation.
- Linux Desktop support is always the question mark – by sales volume it is a platform we could drop, so we evaluate it each time we ship a new major version basis. But with the Linux port already done, help from Linux users on platform-specific code, and Linux running the same drivers as Windows, it’s not that hard to keep it working. If we can run the same next-gen API on Windows and Linux, that would be great. We don’t have the resources to do a port to a new graphics API only for Linux.
(In other words, whatever OS you care about, we’re not looking to drop it.)
How Am I Different?
The next question to answer is: how are these new APIs better than OpenGL? How are they different from OpenGL? How are they different from each other?
All four new APIs aim to provide higher graphics performance and fewer driver bugs, and they all do so with a few basic architectural changes that make them different from OpenGL:
- Threading, synchronization and queuing are all explicitly handled by applications with new APIs, rather than having OpenGL do these tasks implicitly without app intervention. This makes it possible to write 3-d code that leverages multicore, and also makes performance more predictable. (With OpenGL, synchronization is done for you, sometimes not efficiently.)
- Expensive operations are explicitly identified, so apps can perform them ahead of time or in background threads. This lets an app programmer know that the app’s rendering loop doesn’t contain any expensive (or sometimes-expensive) operations. (With OpenGL, expensive work sometimes just has to happen in the middle of rendering.)
- The new APIs let applications manage memory with more control than OpenGL. Here Metal differs from the other three APIs: Metal’s memory management is really “a better OpenGL” in terms of design (the driver still does a lot of work, but the rules for memory management are very clear),while Mantle, Vulkan and D3D12 all give applications control at a much lower level – basically with these three, apps manage graphics memory entirely by themselves.
A key observation: these four new APIs are all a lot more like each other than any of them are like OpenGL. If you ask me to write a rendering engine that supports any two of OpenGL, Mantle, Vulkan, Metal, or D3D12, my job is pretty easy until you add OpenGL into the mix. This is because OpenGL is missing fundamental operations possible in all of these new APIs, e.g. preparing a GPU workload on two threads in parallel.
Supporting Multiple APIs
In the future, I think it is possible that X-Plane could support more than one 3-D API. This is not an uncommon thing in the game engine world – lots of game engines support multiple back-end APIs; pretty much any title available for Playstation, Windows and X-Box is already doing this, as are many games ported to the mobile space. Typically the game engine abstracts the rendering API behind some kind of general purpose drawing layer.
To a limited extent, X-Plane already does this, and has been doing it for a while: we support three different rendering paths within the sim (HDR, no-HDR, and no-HDR with volumetric fog disabled). X-Plane 9 supported three paths as well (fixed function, shaders, and the in-development HDR mode, which was not accessible to users, but was in process for at least the last two years of X-Plane 9). Game engines often have to do this when the difference in capability between their high and low-end hardware is extreme.
We’re Not Going to Drop OpenGL
If we ever adopt a next-generation API, I do not think we would drop OpenGL support. All of the new APIs have something in else in common: they don’t run on old hardware. If we want to capture higher performance on DirectX 11+ hardware before we are prepared to drop anything before it, we’ll need to support OpenGL as well.
- In the mobile space, the iPhone 5 is very capable but can’t run Metal.
- In the Android world it may be that users have modern hardware and old drivers incapable of running Vulkan (due to carriers not updating their OS).
- We support Intel GPUs because they are very often the only GPU a user trying X-Plane for the first time has access to, and some of these may not be able to run modern APIs. (For example, a Sandy Bridge i5 is still a nice CPU with a usable embedded GPU, but it’s not a DX11 part.)
Which API Will You Choose?
The short answer is: it’s too soon to tell, and it might not just be one API. The real cost will be supporting any graphics API other than OpenGL. Our preference is for as few APIs as possible covering as many operating systems as possible, so if Vulkan ends up having wide platform coverage, that’ll be great. But if it turns out that we need to go to a few places to get high performance, we may have to swallow that pill.
It’ll Be Done Tuesday, Right?
This isn’t something that I’m going to start coding tomorrow. Vulkan isn’t even released as a spec, OS X 10.11 and Windows 10 haven’t shipped, and there are plenty of things I can do now with the existing OpenGL rendering engine to make X-Plane faster for everybody.
The process of supporting a new API will probably also start with a cleanup exercise designed to limit how much code is talking to OpenGL directly. So this is a long term architectural change in the sim, not something we bang out in a few weeks.
What About Plugins?
Plugin developers may be wondering: how is my plugin going to work if you move to another graphics API? Right now, plugins use OpenGL directly.
I think the answer is that an X-Plane running on a next-generation graphics API may have to also be running OpenGL, just for plugins; the app would have to create an OpenGL environment that looks believable for plugins to render into, then composite the results with X-Plane’s work. This implies having some kind of interop facility as part of the 3-D API. (This almost certainly exists on Metal via IOSurface; I don’t know about the other APIs.) It’s too soon to know what interoperability options will look like between OpenGL and next-gen APIs – that’s something where the devil is in the details.
An OpenGL sandbox for plugins is actually what we planned to do to support a Core-only OpenGL profile on OS X; going forward we may decide to target Metal instead of Core OpenGL; if we’re going to go to the work of sandboxing plugins in an OS X specific way, we might as well get the fastest API possible.
It took longer than I wanted, but we’re on to beta 3. If you have X-Plane 10.40 beta 2, it will auto-update to beta 3. Beta 3 fixes a few big bugs in beta 2:
- Crash on startup for Mac users.
- Poor framerate on Windows with NVidia cards on prop planes when the props are on.*
- Legacy GPS not finding airports.
Full notes with the bug fix list is here.
Normally I try to get everything new in a release into beta 1, so that we’re just debugging during beta. But some of our internal plans have changed a bit, so I think there might be more features coming in a later 10.40 beta. I’m hoping to have that sorted out by next week.
Please keep filing bugs when you find them (on the bug report form, not the comments section). Please do not:
- File a bug and then tell me on the comments section. We already have the bug report!
- Ask if you should file a bug report. It takes just as long to handle the actual bug as to read the “should I file a bug” email. If the email is shorter than the bug report, it’s incomplete and we don’t even know what’s going on. If your email is the size of a bug report, just file the bug report!
Linux users running the unsupported open source driver: we already have a bug that it doesn’t work – for now if you run with –no_ubos –no_array_tex you can run, but this is not a long term solution.
* That’s that new OpenGL code we’re running. The slow down is only -barely- noticeable on my dev machine with a GeForce 680; it’s a 3% hit. Fortunately Jennifer was able to reproduce the full 25%+ hit that users are seeing. This is why we have beta, and why we try to get new OpenGL code into X-Plane incrementally. It’s definitely a case of write once, debug everywhere.
Posted in News
by
Ben Supnik |
X-Plane 10.40 beta 3 should be out if things go well; I’ll post more on the state of the beta when it’s released. In the meantime, it’s been five years since I’ve ranted about this, so:
When you file a bug report, always be specific!
This is not a good bug report:
Radio tuning does not work in any aircraft.
The problem here is the word “any”. Whomever wrote this bug summary tried a particular aircraft in X-Plane (or maybe even two or three), found a bug, and then assumed that the bug applied to all aircraft. Whatever actual aircraft were tested are lost from the bug report.
Here’s what happens when we get a bug report like this:
- We read the bug report and find it doesn’t tell us which aircraft had the problem.
- Our tester picks one, say, the C-172.
- Murphy’s Law kicks in and the C-172 turns out to be an aircraft that does not show the bug.
- We email the user back with “cannot reproduce – what aircraft did you use.”
In other words, whomever is triaging this bug has now spent time testing and emailing to get information that should have been in the bug originally. This lengthens the time from when the bug is filed to when we can fix it.
When you file a bug, you know what aircraft you tested – tell us what it is! If you tested two or three, list all three. You don’t need to do any more testing work – you just need to include a little bit more information. Our tester and programmers will then go look at the exact aircraft you specified, and we’ll find the problem.
(If you are reading the developer blog, you probably know all of this – I’m really writing this up so we can link to it when sending requests for more information to users.)
One of the new features in Plane Maker 10.40 is a variety of classification information available for aircraft files, found in the Standard > Author window.
These fields are not currently in use in the X-Plane user interface, but we do plan to use them in the future—we want to do away with clunky folder-based browsing of aircraft. Instead, we want to allow users to browse & search through their aircraft in a much more flexible way: by aircraft name, manufacturer, category (general aviation, airliner, glider, etc.), and design studio.
So, for instance, you might want to see just the planes that were developed by Carenado, so you would select Carenado from the aircraft studio dropdown. Or, you might want to see just the general aviation planes built by Cessna, so you’d select General Aviation from the category dropdown and Cessna from the manufacturer dropdown. Or, you might want to search for all the aircraft with “747” in their name, and see your 747-100, 747-400, etc.
We think this will be a serious improvement over folders, which allow you to organize your aircraft in only a single, fixed way.
But, before that happens, we’d like to get as many aircraft authors on board as possible—we can’t know, for instance, which design studio created an aircraft unless you add this info to your ACF files.
So, grab 10.40, open Plane Maker, and add this classification information to the aircraft you develop!
(As an aside, you might be wondering… what’s the difference between the aircraft’s “author” and “studio”? The idea here is that the “studio” is the group producing the aircraft—you want your “studio” to stay consistent for all the aircraft your group produces, while the “author” field credits the actual people involved in the plane. Your studio might be “Amazing Sim Planes,” while your “author” field might be something like “Jane Doe, flight model; John Doe, 3-D modeling; Jack Jones, texturing.”)
Posted in News
by
Tyler Young |
I’m declaring WorldEditor 1.4 to be final. From now on, you must use WED 1.4 to upload to the X-Plane Scenery Gateway. If you have not upgraded yet, please do; you can download it here!
X-Plane 10.40 beta 1 is here now…you can download it by checking “get betas” and running an update.
This is an early beta and I strongly recommend running it on a copy of the sim, not your main setup.
Update: release notes are here!Release notes are coming soon; I’m posting this now because I want to find out if we have new OpenGL driver incompatibilities to fix. I’ll be in Hartford all weekend, but I’m hoping that if there is a broken graphics card, I can get a patch before I have to go.
So: please try it – on a copy. If you hit a graphics card problem, please file a bug!!
Update 2: there’s a hard crash on startup that appears to be affecting perhaps all Linux users, as well as what I’m guessing is a tiny handful of Windows users. I’ll try to get this fixed for beta 2. If you have this crash, please do report it with log files so we can catch all cases. You’ll have to use the updater to update to beta 2 when you see the announcement because the crash is happening before the auto-update check.
Update 3: beta 2 is out and fixes both the Linux startup crash and the Windows startup crash, which turns out to be specific to AMD processors. You’ll have to manually run the updater to get beta 2 if you were having crashes. Thanks to the several users who ran a ton of custom builds for me last night to isolate this.
Posted in News
by
Ben Supnik |
X-Plane 10.36 has a button in the rendering settings screen labeled “set all rendering options for maximum speed”. Our recommendation for tuning your X-Plane settings has been to start low and build your way up, so that you don’t end up with one setting “hanging” the system at a low framerate (which stops you from seeing the affect of other changes).
This button was a good idea in principle, but in practice it had a few problems:
- The lowest settings are really just astonishingly ugly.
- Some of the settings that get turned off are nearly free, so pressing the button hurts graphics quality unnecessarily.
- Once you minimize your setting, what do you turn up? I’ve seen too many forum posts where users have picked a few random expensive settings and complained about a poor trade-off (e.g. poor performance for the hardware and quality).
So in X-Plane 10.40 we’ve replaced this single button with five pre-made presets: minimum, low, medium, high, and extreme. Each preset is hand-built to try to make good settings trade-offs; instead of having to fish for better visual quality after minimizing, you can simply try 2 or 3 presets, based on your hardware. If you have a very new system, try “high” and “extreme”. If your system is really old, try “low” and then go on to “minimum” or “medium.”
The settings aren’t coded into X-Plane; they come from a config file, and this is important for the process of tuning the presets. The truth is: the presets as picked in beta one are probably not that great. I did run them on my machines, but with only a few computers, it’s hard to know what a good setting is for most users.
In X-Plane 10.40, it will be possible to run the framerate using one of the rendering setting presets instead of one of the fps-test numbers. This will let us get direct, controlled measurement of the performance of specific presets on real machines. My hope is that by collecting this data and tuning the presets up and down, we’ll be able to dial in good compromises in terms of speed and quality.
I’ll post details on how to use the fps test once 10.40 goes live, so that we can start collecting data.
In the long term, the rendering settings need a lot more than just presets; they need a massive simplification. But within the scope of X-Plane 10.40, the presets will hopefully provide a better user experience, less time spent tuning X-Plane, and be a good stepping stone toward a better UI.
Finally, for advanced users who like to tweak things: it will be possible to edit settings.txt and change the presets. I see this in the forums a lot:
User 1: I have an Intel i7 clocked at 1675 ghz and I’m getting 10 fps. What’s wrong with X-Plane?
User 2: that’s weird – I have an Intel i5 clocked at only 900 ghz and I’m getting 350 fps!
With the presets, user 2 can build his settings into a preset and send the file to user 1, who can then try those exact settings and see how performance runs. Both users could also run our presets in the fps test and see if the performance problem is due to different hardware, different rendering settings, or different add-ons.
Posted in News
by
Ben Supnik |
One new addition to Version 10.40 is almost guaranteed to be controversial: at the user’s discretion, we now collect anonymous usage information.
Before you light your torch and grab your pitchfork, let me explain why we have not become the next Spyware Kings.
The X-Plane 10.40 installer has a screen to explain the data collection, and a checkbox to opt-out. If X-Plane is already installed, you can toggle data collection on or off using the Operations & Warnings window in 10.40 and later.
We will only collect usage information from users who have that checkbox enabled. If you upgraded to v10.40 from an older version of X-Plane, for instance, the checkbox in the Operations & Warnings window is disabled by default.
(But, read on to find out why you should go turn it on!)
In our case, we collect two main types of information:
- system configuration (including your operating system, CPU model, graphics card model, amount of RAM, what language you’ve selected, and so on)
- X-Plane usage (including which aircraft are flown, which airport you start at, and so on)
This information is 100% anonymous. Essentially, all we ever learn is that some user, somewhere was running Windows with a Core i7 CPU, 8 GB of RAM, etc. and they flew the C172 from KBFI. We cannot trace this information back to a specific person.
No.
Since everything we collect is anonymous, it obviously does not include contact information like your name or email address. We can never use the information collected to contact you in any way: no marketing, no spam, no way to bug you.
In essence, your usage data helps us make better decisions about the future of X-Plane.
For instance, if we found that 50% of users were running 10 year old machines, we would need to think long and hard about increasing the system requirements in future versions.
Similarly, if we found that only 10 people ever flew a particular aircraft, we could conclude that users weren’t very interested in it, so we probably shouldn’t create a new aircraft that was very similar. Likewise, if 25% of flights involved the 747, we might decide that people really like big airliners, so we should probably create another.
This is roughly a billion times better than the way we currently make decisions about this type of thing (both in terms of hardware support and sim features). The current model looks like this:
- Make a guess about what users want
- Argue with the other developers who guessed differently
- Ship something that users may or may not actually like
I can’t stress how much having actual data will improve our ability to make X-Plane the product that users really want.
Why you should participate
Sending this anonymous usage information is like casting a vote—in this case, a vote for us to support the way you use X-Plane. When you send your usage information, you cast your vote for us to support your hardware configuration, to build more of the planes you like to fly, or to improve the airports that you like to fly at.
Just like in electoral politics, you have every right to abstain. But abstaining means we’ll hear other people’s voices and not your own.
If you’d like to participate, you just need to do the following:
- Get the 10.40 update and launch X-Plane
- Open the Operations & Warnings dialog
- Check the box labeled “Send anonymous usage information to help make X-Plane better.”
Posted in News
by
Tyler Young |
One of the new things in X-Plane 10.40: more modern OpenGL code. I mention this because that new code will probably create chaos during the early betas; we’ll get the bugs fixed as quick as we can.
The problem is that OpenGL can be an exercise in “code it once, debug it everywhere”, and while I have tried to set myself up with a wide range of hardware, I don’t have one of every combination of drivers and GPUs that X-Plane runs on.
X-Plane 10.40 will be a longer beta, like 10.30 was, so we should have enough time to work out the kinks in the new code. Having to do this kind of debugging during beta is annoying for everyone, but it’s also necessary to advance the sim forward.
When 10.40 comes out, if the beta doesn’t run on your hardware, please do report a bug; often users assume that if they see the bug then everyone does, so someone else will report it. Not only is this often wrong (because everyone assumes someone else will report a bug), but it might be that your combination of hardware and drivers is the only one that shows the bug!
Update: yesterday at the 2015 WWDC Keynote, Apple announced that they were porting Metal, their Apple-specific low level high performance 3-d API, from iOS to OS X. I will comment on this next week, after the WWDC sessions on the desktop version of Metal are available on the web. In the meantime, don’t panic – this definitely isn’t the end of the Mac, Windows, X-Plane, or the universe.
Posted in News
by
Ben Supnik |
I cut a new release candidate for WorldEditor: WED 1.4r2 – please update to this latest build. (1.4r1 had a crash-on-export under a relatively rare configuration of lines in a scenery pack.)
Posted in Tools
by
Ben Supnik |
