Just a quick update on our progress with Vulkan and Metal. We last spoke about this on the live feed a few weeks ago, but we’re a little further along. Here’s the summary:
- Plane-Maker and Airfoil Maker run in Vulkan and Metal.
- X-Plane runs in Vulkan and Metal up to the main menu (e.g. the app starts) but can’t yet fly or show scenery.
- The Vulkan and Metal code runs on Mac, Windows and Linux.
- The Vulkan code runs on Nvidia, AMD and Intel drivers.
- All shaders are ported.
- All of the zoo animals (abstractions around part of the graphics engine) are now complete. We killed off the last 2 or 3 since the live feed.
For the last two weeks, Sidney and I have been working to port all rendering passes to the new code, so we don’t have to go through OpenGL to fly the aircraft. I lost a few days dealing with this:
That turned out to be a single if statement that got reversed deep in the mesh drawing code during one of the porting steps, resulting in some of the runway lights being replaced with random pieces of … heck, I never figured out what the wrong mesh was, just that it came from some other unrelated part of the sim and changed as the camera moved. To make matters worse, the error only appeared on the Mac, so we couldn’t use Windows OpenGL debugging tools to find the issue.
The silver lining is that once we are all Vulkan/Metal, we’ll have at least four separate debugging tools to go after bugs like this.
We don’t have measurements of performance yet; once we can sit in an aircraft in X-Plane running Metal or Vulkan, we can at least get some initial performance numbers.
Good to know. I’m excited to see the performance comparisons.
Keep the good work.
This kind of reminds me of flying around Mars in past XP versions. Except this looks more like Saturn.
Does the already-more-efficient Vulkan pipeline include any new multi-thread-specific improvements that are not inherently part of Vulkan? Or is it intended to be a play-it-sane-single-thread replica of the current GL path?
Good question! The _rendering_ path is “play-it-sane” – we’ve tried to add as little risk to the port here as possible by not redoing the model.
But the _loading_ path is significantly more multi-threaded. In porting to Vulkan, a number of operations that used to be part of the GL driver became par of X-Plane’s code, and so we had to go “where we do X, which we never did before”, where X was some new code, like building all variants of a shader for different surface formats, or scheduling a DMA.
Our policy for this has been “do it right the first time” – this kind of work is universally offloaded to worker threads. So in Vulkan, when a DSF load finishes, it’s _really_ finished — entities are in VRAM, shaders are fully compiled for every use case we’ll have, etc. I am hoping that this will result in significantly less stutter during DSF loads and scenery transitions.
(The planet rendering code got an almost-complete rewrite as part of this…planet loading is fully async and the meshes are recycled using a single grid that is formed by shaders into a planet-shaped sphere. So a bunch of planet-related stutters should be gone – even when OpenGL is the back-end.)
Right so any gains out of the box beyond load times will be purely from Vulkan efficiency rather than multithreading?
I’m sure you have plans for which operations get the multithreading treatment but do you expect a lot of trial and error here or is it quite “straightforward :)” to understand where Xplane can be best optimised (make the greatest gains) with multithreading?
Or is synchronisation and mutation of operations still a big concern once you begin to assign related tasks to different threads?
Will you be concentrating on CPU gains since this tends to be the Xplane bottleneck?
I must say it is all very exciting, a bit like cutting the wires to defuse a bomb kind of exciting 😛
So first, to be clear, the _first_ perf improvement we are targeting is un-bottlenecking the CPU by having less time in the driver on the main thread by going to Vulkan. We hope and expect that draw calls will just cost less on Vulkan. In our looking at performance problems post-11.30, CPU bottlenecks came up over and over, so I think this matters a lot.
Once we are on Vulkan, we can then re-profile and see what the next most important thing is. It’s important to note that the biggest problem may not be the same after Vulkan compared to before, because the relative balance of types of CPU work will have changed. So it’s too soon to tell.
In the long term, we can make things faster both by doing work more efficiently (our culling structure is an example where we think we can just rewrite it with better code that’s more appropriate for modern CPUs) and by using more threads. It’s hard to say how straght forward multi-core will be because it only makes sense to move work loads to other cores if those work loads will be expensive _long term_. If the work load can be made fast by “not being dumb with the code”, we should do that first.
Finally, GPU usage _is_ important too, and we’ll have a much better view into this (probably the first really good look) once we’re on Vulkan and Metal and we can see things like wave-front utilization, dispatch efficiency, etc. We’ve seen some cases where we’ve caught problems and fixed them, but with general purpose GPU profiling tools this will be more straightforward.
Thank you for that detailed reply Ben, I know your time is especially valuable right now.
It will be interesting to see just how much new game engines can benefit from utilising multiple cores via Vulkan, more especially stand alone engines and flight sims such as Xplane with their specific requirements but it seems unlikely having more than 4 cores will count for much on Xplane11 Vulkan as with most current games but hopefully Xplane scales well to for multi core use.
For layman such as me who do not fully understand where and how the best gains can be made within Xplane this is a very interesting journey and I’m sure there will be a wonderful long and detailed blog post detailing that journey, replete with anecdotes, once conversion is complete. Geek heaven. 🙂
Can’t wait to see how different CPU/GPU combos work as well, I will base my next upgrade upon it.
I can say this: as an API/library/driver standard, Vulkan gives us ways to do multi-core right in the future that were never feasible in OpenGL. OpenGL is like a deli counter with only one person serving…
Regarding CPU vs GPU usage. I recently modified my sim setup from having two PC for external visuals each with two independent views (on two monitors) into fourth PC each with single view on single monitor. This allows me to trade some of fps gain into better visual settings. And surprisingly now each of these machines is GPU bound! (i7-9700K@4,8GHz + GTX1080Ti, 4k monitor). I do just use standard HDR settings with no reflection, maximum number of objects, scenery shadows, 4xSSAA+4xFXAA – so nothing fancy. But even so now my CPU frame time is only 50-75pct of GPU frame time.
I saw increased usage of GPU from 11.30 betas as some trade of for less stuttering. So if Titans is not next suggested GPU for XPL I would prefer any optimization here as well. 🙂
Anyway good luck with Vulcan transition and I keep my fingers crossed.
Right – if you go for 4K _and_ SSAA _and_ HDR, you can finally push enough pixels to keep a 1080 occupied. My personal view is that anti-aliasing is a waste at 4K, but if your monitors are really huge (physically) then maybe it’s useful.
Really excited to hear some details about this, thanks! And also:
>Our policy for this has been “do it right the first time”
Fantastic.
Does the Vulkan could solve the issue that when loading dsf files sometimes kill all the cpu performance and fps drops suddenly?
Ben implied (or specifically stated) this in the comments, so yes. Though if you have a slow hard drive, all bets are off.
The hard drives is not the point.The dsf file is very small that ssd and hhd can both do well in reading from disk.
That’ the plan, read Ben’s responses, they are very detailed.
“…So in Vulkan, when a DSF load finishes, it’s _really_ finished — entities are in VRAM, shaders are fully compiled for every use case we’ll have, etc. I am hoping that this will result in significantly less stutter during DSF loads and scenery transitions.”
I think the question though is whether or not the DSF load process itself will be done in a way that does not produce stutters. My understanding (based on a blog post from 2017) is that X-Plane does this load now, but the OGL drivers are doing something that interferes with the existing XP process. The interference causes the CPU cores to spike to 100% during the load, causing the stutter. I’m inferring from the comments by Ben that the Vulkan code will give XP full control over this load process, which will then allow them to debug any stutters (and of course fix them!)
Exciting times for Xplane! It sounds like you guys are really close to finishing your port to Vulcan!
Please How do I can make update my X-plane11
Run the installer and choose update X-Plane
Thanks Ben. Really appreciate updates like this. Cheers.
I think if you removed all zoo animals from the sim, hardly no one would miss them. #gonebutnotforgotten
Our hope is to branch out in the future with X-Zookeeper, since there hasn’t been any hardcore zoo sim game in ages and it’s a very untaped market.
@Sidney, I think Tom misunderstood that by zoo animals we’re referring to, like, you and the other programming staff. 😉
Lions and tigers and bears…
You know the rest. 😉
Quote: “All of the zoo animals (abstractions around part of the graphics engine) are now complete. We killed off the last 2 or 3 since the live feed.”
interestingly, what were the recently hunted three preys, if you could quickly enumerate them briefly?
“Framebuffer capture” was one of the big ones, e.g. the ability to read image data back from the GPU. We use that for screenshots, video capture and ATC layouts. It has to be reasonably performant for video capture.
“Occlusion queries” – we don’t use them heavily, but we measure the obstruction of the sun disc to modulate the sun glares.
And we recently decided we needed separate texture samplers and (aliased) image views. These are bog standard in Metal and Vulkan, but in OpenGL they aren’t on the Mac and OpenGL offers a different way of accessing the same functionality (e.g. mutating objects ‘cheaply’). So I had originally thought we’d build these in the future when we could drop legacy Mac GL drivers.
with thanks for the clarificaiton.
i was kind of educating myself based on your answer:
———-
for the “Framebuffer capture”, am sure this also paves way to better harness multi-monitor setup – does it ?
i was kind of thinking – though this is not relevant – suppose a scenario of two GPUs; would they share one single frame buffer – or is it each GPU will have its own frame buffer?
———
for the “Occlusion queries” i have watched::
https://www.youtube.com/watch?v=LMpw7foANNA
Now based on your info “we don’t use them heavily” is that because of a performance hit that you do not use them heavily, or just a matter that they are not needed in most of scenarios through out the sim.
This sparked an idea – at least how i theorize it for my self – that in future you can tap RTX ray-tracer setting it to a depth of 1 – to achieve same result but at hardware acceleration bonus.
Framebuffer capture is irrelevant for multi-monitor purposes, it’s used in order to grab screenshots and do video capture of the rendered scene. Additionally, a second GPU will actually not do any work for X-Plane, we strictly talk to one GPU. There is some theoretical advantage to multi GPU support, like you said, each GPU could drive a single monitor or one eye in a VR headset. However, multi GPU support comes with a lot of overhead and a lot of potential problems, so I don’t think we’ll add support for it in the near future. Plus, unlike CPUs, GPUs actually still get better each year and we are mostly CPU bound, so improving CPU performance is definitely the major focus right now.
With regards to occlusion queries, I don’t see how RTX would provide any benefit here. Occlusion queries are already done in hardware and the results are read back asynchronously. And they work on all hardware, without relying on vendor specific extensions. No, the reason they aren’t used isn’t performance concerns but rather that there aren’t too many use cases for them in X-Plane, unlike, say a shooter with a tight level where most geometry can be easily clipped based on occluders.
What about the atmosphere? Maybe it’s already worth changing the clouds? They look awful. I do not understand, do not you see it? Or are you testing your product without any clouds?
One step at a time. Rome was not built in a day!
Easy. Once x plane is successfully ported to vulkan, every lapses will soon be gone and it will be a way more better sim in terms of performance! I am sure much of the current x plane’s limitations are because of the OpenGL platform behind it!
+10
So by FlightSimExpo 2019 should you have some Vulkan and Metal stuff to show off?
I plan on being there and seeing the team again like I did last year.
Thanks for this great news. I rent an Oculus Rift recently just for seeing how X-Plane is in VR, and it is soooooooo… great and feels like reality. Yesterday I’ve ordered one and I’m hoping that Vulkan can gain the performance a little bit.
best regards,
Carsten
Great news!
Especially the DSF loading, because in VR it does not only causes stuttering but it blacks out the image in HMD for a few seconds (at least in SteamVR it is showing the grid).
I’m flying in VR so I would like to ask 2 questions:
(I know that VR is not in your first priorities and also that VR users are a small percentage of the total X-Plane users, but since you are rewriting code to port to Vulcan maybe you can enhance VR a little).
1) Is it possible to add support for Nvidia Single Pass Stereo for VR?
I think that if this is possible, it will boost the VR performance (at least for Nvidia GPUs users, which I think are the most in VR).
2) Is it possible to add more AA options like MSAA?
I’m currently flying with a Lenovo Explorer (GTX1080) and I found that I can get much more clear cockpit instruments (I can read most of the G1000 indications) and scenery, if I set the AA to FXAA and SteamVR SS to 350% than set AA to 2xSSAA + FXAA and SteamVR SS to 150% (I’m getting about the same 45 FPS in these 2 scenarios with C172).
I don’t know why the SteamVR SS adds more clarity and sharpness to the HMD image than the native X-Plane SSAA, but it’s a fact.
Maybe a combination of native MSAA and SteamVR SS could produce even better image quality with about the same performance.
I am interested in X plane VR for professional use at a flying school. The limitation at the moment is the clarity attainable with consumer grade HMDs. I recently evaluated VRgineers Xtal HMD with X plane 11. Unfortunately the clarity of the Xtal HMD with X plane was significantly worse than the same HMD with DCS world. I don’t know the exact graphics and steam VR settings used for the demo. Xtal probably has the best potential clarity of any wide FoV HMD currently available. I think there is great potential for VR in professional flight training especially for helicopters, however clarity needs to improve to the point where an EFIS PFD is easily readable. VRgineers are planning further improvements to their HMD and I would hope they could work with Laminar Research to achieve an effective solution for the professional training market.
Fully agree with you… I must say those VR numbers are low now mostly because VR devices are expensive, but once you take off with the little Cessna with those in your eyes, the immersive experience will pay for itself. It’s a matter of time that more and more people will move from 2d screens to really enjoy this new world of magic. And we hope that Laminar will also see that a game changer and kept that advantage in favor of a better and improved sim platform. Cheers from San José, Costa Rica! XP11.3+Oculus rift user 🙂
Oh, for sure. When a decent VR headset with, let’s say, 5k resolution and FOV of 160 or greater comes around with a price tag under 300 bucks, I’m in 😀
well, how about 210 FOV for a USD 3,200 ?
https://www.starvr.com
Thanks for the update, Ben!
Great work!
Hi Ben, do you think it’s possible to bring back higher AA through datarefs? For everybody who is NOT running in 4K but has GPU time to spare (for me, that’s a lot with a 1080ti@720p) that was extremely useful. But (I think) since 11.30, the screen is glitched once you dial in numbers higher to what equals the 8X AA slider. Even in 1080p, there were huge gains in image quality when using higher digits for the AA x and y axis AA datarefs.
What AA settings were you looking to dial in, exactly?
Depending on the resolution (you will hit the wall pretty hard at some point), I’d use 3/5 or 2/6 or 4/6 instead of the standard 2/4 which would be 8x AA (if I remember correctly). I am not saying I am fully understanding it, but what I do know is that this lever was the only one that gets you a completely shimmer free (think poles, powerlines) sim. 720p with higher AA easily beats 1080p in terms of image quality/stability (given your display has a good upscaler, for example Sony TVs excel at this).
The only other way to achieve this would be X-Plane allowing super resolutions, just like NVIDIA DSR. The problem with DSR is, it doesn’t work for a base 720p resolution (without elaborate hacks anyway). And at 1080p you won’t be able to raise AA much before you run out of fillrate.
I have no idea what causes 11.30s glitch when messing with these variables, but if you could “fix” it, or even made a higher setting than 8x available through the slider, that would be super cool.
No update available when I run the update program !
It’s normal ?
i have watched this video
https://www.youtube.com/watch?v=hvdAVsjrQRM
the outcome is – it seems with the shift to VULKAN — more GPU utilization will make performance be more GPU bound — yet every freeing for the CPU will benefit the core x-plane core system that i suppose is CPU bound.
all in all – we are eager to see the future
Do you actually have a mode – for developers – where literally all visual effects and scenery outside of the airplane is turned off. Only the most rudimentary details like the horizon, runways would be displayed. Wouldn’t it be useful/interesting to make this available to users – if it exists?
“Developer mode” (when we aren’t working on visuals-related stuff) is basically:
That gets you the fastest load times possible.
Thanks for the exciting update. Can you tell us something about the touchdown smoke effect coming back in raplay mode?