Last week we sent out our first build of the Vulkan/Metal ready X-Plane (which will be version 11.50) to an external sight, and last night we sent out the first private beta.
Our plan is to move to an open public beta soon once we have some feedback on how well the build is working. When that is will depend on the bug reports; I’m crossing my fingers.
How It Works
In X-Plane 11.50, there is a check-box in the rendering settings that enables Vulkan or Metal; you’ll have to restart for the change to take effect. If the sim crashes really early (e.g. before the main menu) it will revert to OpenGL to keep you from getting “locked out” but random crashes while flying won’t do this. There are also command line overrides to control the driver for people running performance testing scenarios.
I should also mention that we’ve changed what the reflections slider does – it’s now like X-Plane 10 and does not attempt to update the environment cubemaps in real-time. (If you really like flying at 5 fps, you can re-enable this in settings.txt – the underlying tech has not been removed.)
What we have found over the last few years is that users will drag every slider all the way to the right, and then be surprised that the sim has poor performance. While I have in the past dismissively claimed that they are doing it wrong (“don’t put every topping on your pizza”) the inevitable truth is that we are violating an industry UI norm by having the highest possible settings run beyond the scope of the fastest possible computers our users can get their hands on.
Now that we have Vulkan and Metal running, we can make some judgments about what will and won’t be real-time. Full scenery shadows are still available and are helped by the Vulkan and Metal driver; a decent machine should be able to run full autogen + scenery shadows at 30 fps.
The Vulkan and Metal back-ends change their approach to running out of VRAM. With the OpenGL driver, when VRAM is exhausted, textures are moved to system memory, and the application stutters while the driver makes this mad last-minute shuffle.
When running with Metal and Vulkan, X-Plane will reduce the resolution of your textures while you fly, in the background, without stutters, preferring to reduce resolution on textures that are not being used right now. The result should be smoother and generally less disruptive. You can still lower the overall texture resolution to better fit your card’s budget.
This new “on the fly paging” is…well, it’s completely new, and I suspect it will need a lot of debugging during beta. It’s an area where we just need to collect use-case data to better tune the algorithm.
X-Plane 11.50 no longer allows for uncompressed textures – if a DDS is present on disk, we will use it. I have to recommend texture compression in the strongest possible terms; while the artifacts are annoying, when we turn it off, everything looks worse due to the VRAM pressure – uncompressed just isn’t a good way to use our VRAM budget. Pre-compress your textures for best results!
A Detailed View
One of the great things about running with the Vulkan/Metal back-end is that there isn’t any dark matter in the rendering path – everything that takes time takes that time when we say so. This means that when we have a stutter we can take the frame apart and figure out exactly why that happens.
One of the last fire-drills before sending out a build happened last week – with the Vulkan back-end and memory paging working correctly, we would still see these violent stutters flying over downtown LA. As it turned out, the code to delete autogen as you flew away from it was too slow and was causing hitching every time a 3 km AG square had to be torn down.
That code is now rewritten and the results are much smoother. Here’s what winning looks like:
This is my old iMac running at 60 fps – it can’t do that with everything maxed out, but when it does hit 60 fps you’ll note the dead even orange bar at the top – that’s consistent framerate. The bottom of the screen shows a block diagram of some of the tasks that went into the current frame render.
With “weird driver behavior” removed, when something stutters, so far we’ve been able to identify it, e.g. the autogen stutters from last week. Here’s what stutters look like:
The orange spikes you see are the stutters – I induced these by command-tabbing to other apps while flying; when the window manager swaps apps it’s pretty disruptive. That big blank space in the middle of the screen is time spent doing something (probably in the window manager) that we do not yet track.
One last show-and-tell pic: for some reason when running at 45 fps, the sim is actually running at a mix of 60 and 30 fps every other frame, which is not good. We can easily see this with our tools:
Here we can see two frames, a long one on the left and a short one on the right. The difference: “acquire surface” is taking a ton of time. The long frame is stuck waiting for the window manager to give us some VRAM to draw into. With this kind of detail, we can at least understand the bug and try to fix it.
Next Steps
At this point the only thing left to do is fix bugs, some of which are still open even as the private beta goes out. We will move to public beta once we have something where we think the initial experience isn’t a blue screen and tears.
Sincere congratulations for your progress on Vulkan. Smoothness and performance could prove essential features in the flightsims landscape, with VR, etc.
Do the new “texture loading on the fly” mean there could be the infamous “blurries” when the system can’t keep up? That was maybe the most common complaint that affected the competitor flight sim forever.
Yes – blurry textures are a new possible failure mode, particularly when you combine low-end hardware with high settings and complex add-ons. In the conditions where this happens (and isn’t just a bug) you would have just had a crash or total framerate failure (e.g. 1 fps) in the old system.
Hmm,
I wonder if the “blurriness” is controllable by the developer. Meaning: keep instrument texture sharp but other textures can be blurry.
Yes – not every texture is eligible for de-rez. So e.g. we don’t derez parts of the panel or the UI.
I don’t know how u guys do it. I would pull my hair out. I’m a xplane11 user and I do enjoy it. My laptop is running 19-32 fps with it with low rendering setting. I pray for u guys. May GOD blessings be on u. Keep up the great work.
when does the Vulkan update come out? is it gonna be iside of 2020 or the 1st of january? just tell me when you think its going to release.
Nice news!!
Thank you for the hard work!
I’m surely waiting for public beta to be release!!
thanks for the effort, cant wait
will we see better performance with clouds?
Great News, LR cancel your Christmas holidays and try and get the out the 11.50 beta before the New Year, I’m so looking forward to this….. Only joking everyone enjoy your time off…. and happy holidays.
Thank you for all the hard work and updates!
Best Christmas Present so far!
(Then again, I haven’t gone to the family get together yet, so…)
This is going to be great!
Thanks for the Christmas update. As a software engineer myself, I’d love to be a part of the private beta.
Hey Ben,
Nice update, and seeing as you did this on Christmas day it’s very much appreciated man. I was wondering when you mention your “old iMac”, what spec are you talking about if you don’t mind me asking?
Have a safe one 🙂
It’s a 2014 5K iMac – so good in its day but getting long in the tooth now – GPU is an R295X, does like 4K single core on Geek Bench 4. I just replaced my laptop with the new 16″ MBP and it is significantly faster – my PC is faster than this iMac too.
I have an iMac 2 yrs older than yours. I am soooo ready for a new one. I know little about Metal. Should I go for the most CPU cores I can afford or will XPlane only use a few and anything above 6 cores will be a waste of dollars?
Looking forward to being able to fly with clouds again
Thanks
I wouldn’t go nuts with the core count – it gets $$.
I have an iMac. Don’t get an iMac FOR x-plane. Get an iMac if you need it for other stuff and also want to play x-plane. In that scenario the bang for the buck can work out.
For the *moment* you want highest single core hyperthreading speed you can afford, and throw the rest of your budget at SSD (do not get a spinning drive under any circumstance) and the Vega 48.
I am lucky enough to have the i9 iMac with a Vega 48. It does a very very good job at 2560×1440, hdr, shadows on. It is playable but kinda wonky at 5K (the card is really not tuned for shoving 5K at lots of fps, certainly not with antialiasing on… and 1440p antialiased looks better than 5k without)
I am sure I could build a pc with an over clocked i5/7/9 and slap in the newest nvidia hotness for waaaaaaay less money and get somewhat better performance (mostly from the graphics card, this i9 is close to what you get get out of an OC’d box), but since I have other compelling needs for an iMac, it’s nice it also runs x-plane well.
Apple doesn’t offer like a mythical 2 core 6ghz i7- all the offerings are 6-8 cores of 3.0 – 3.7 base (4.6 to 5.0 turbo boost) i5 and i9, so you are getting multicore anyway, and the turbo is kind of up to the thermal load of your box vs how many cores the system is trying to use (more cores at once, lowers/eliminates turbo boost)…
So you kinda want to max out base clock which means the 3.7ghz i5 or 3.6 ghz i9.
Those are also the ones with the higher turbo boost. You might think that the i9 with the 5.0ghz is better, but it might top out at the same or lower sustained speed due to either thermals or multiple cores being engaged.
As far as 6 cores (i5) vs 8 (16 with hyperthreading in the i9) goes – Ben, chances of the render loop going “embarrassingly parallel” are probably pretty low right? Because if you say did the autogen on separate threads you’d still need to jam the results into the main loop and that could slow things down… or something?
Thanks for the advice. Much appreciated
Thanks for including me on this private beta…. Ops, sorry my mistake, I’m not on it… I’ll be sure waiting for the public beta, because, I don’t know, I probably have being a bad person this year and didn’t deserved this nice Christmas gift….
Good luck and have fun for those who deserved it… you were probably very nice people..
It’s not a gift. It’s a beta. The point isn’t to get the shiny new thing first, it’s to _find bugs_.
First round went to people in our third party developer program. We’ll widen the circle as we get feedback.
Thanks Ben, looking forward for that.
What is your “thrid party developer program”?
I’m a third party developer, my add-on aircraft are now my main source of income, so I’m very curious.
We have a prorgam where third parties under NDA are in a slack room and can easily get access to dev builds and do Q&A. Email support to get an invite.
Bruh moment
Excellent update! Thanks, Ben. Thoroughly looking forward to the Vulkan update, when ever it arrives.
On a side, but related, note, has LR verified that graphics drivers can support Vulkan? I was running GPU-Z today, for a different reason, and saw that the Vulkan support was not checked, and it’s running the latest driver, as of this morning (Nvidia GeForce 441.66).
Latest AMD and NV definitely can – the box doesn’t auto-check, you have to do it. In the AMD case, you need the latest drivers for proper OGL/VK interop for plugins.
Hey Ben, I just checked again and GPU-Z doesn’t allow the checking of those check boxes; they are for displaying the availability of the technology. The latest WHQL driver version (441.66) is installed.
When I checked the Intel Integrated Graphics adapter, it does show Vulkan compatibility, so I’m thinking there may a compat issue with this RTX-2070.
The drivers can definitely run Vulkan, if GPU-Z doesn’t show that you have Vulkan support, it might actually be your GPU. Nvidia supports Vulkan all the way back to the GeForce 600 series. If you have a Notebook with a GeForce 600 though, do note that Nvidia used to package previous generation GPUs for notebooks as current gen ones (so a notebook GeForce 600 could potentially be a GeForce 500 series GPU).
@Sidney
If it’s an Fermi based GPU, he couldn’t use the Geforce 441.66 driver. All GPUs supported by this driver should also support Vulkan. So that’s a bit strange.
When we run v11.50 for the first time, what is the situation with aircraft? will they run or will the developers need post the required v11.50 fixes, or what will run or will needed to be pulled out (plugins) to get an effective simulation.
Most add-ons should hopefully just work. X-Plane creates a bridge OpenGL context, which is used for 2D plugin drawing, and takes care of synchronizing it with the Vulkan/Metal world. This means that plugins drawing in 2D, ie UI and panels, will work as they are. 3D drawing isn’t supported, because we are limited by what we can share with OpenGL and there’s also a bit of overhead involved with switching between the worlds.
I have tested a couple of third party aircraft. FlyWithLUA based plugins tend to work quite well, the ToLiss A319, FF 757 and 767 as well as all FlyJSim planes. The one plugin that didn’t work was the FF A320.
Thanks, I’m not surprised the FF A320 Ultimate does work as it is based on the Chromium Embedded Framework (CEF)… I think a fix will come quickly. As will all the Vulkan update fixes 🙂
Thank You!!
Merry Christmas To All
“When running with Metal and Vulkan, X-Plane will reduce the resolution of your textures while you fly, in the background, without stutters, preferring to reduce resolution on textures that are not being used right now. The result should be smoother and generally less disruptive. You can still lower the overall texture resolution to better fit your card’s budget.”
Does this mean that we should use a higher texture resolution in the settings and let Metal/Vulkan lower it if needed?
//David
I would not recommend it. The loading will be longer, because the pager has to kick in a lot in order to fit everything in. On top of that, not all textures are scaled down uniformly, instead the pager will try to make a best guess effort deciding what to downscale.
Thanks for the info! I’m really excited about this, having an old computer myself, somewhat similar in CPU specs to your iMac. I have one question. With the OpenGL driver what FPS were you getting? I do realize that much of that jump came from optimizing the GPU usage, but do you think that Vulkan will also help in the CPU department? In my particular case a have an i7-4790 (non K) paired with a 1660 Super that I just got. Previously I had a 1050 Ti. I did see an improvement in performance, but on heavy stock sceneries (like default KMIA for instance) the jump in FPS was not that much. I think it is CPU related (although the CPU usage is about 50% at the most in that situation) , hence my interest in knowing if Vulkan would help improve that a bit. Thanks in advance for taking the time to answer, and once again, thanks for the great news!
Wait – let’s be clear! There is approximately _zero_ GPU-side benefit to these new APIs.* They are running the same shaders doing the same rendering work. The benefit is _all_ CPU side where we tell the GPU what to do faster. This is useful for people who can put a new GPU in their machine but are CPU bound. But if you are GPU bound (e.g. lower res = faster) this won’t help.
On my iMac, I went from about 45/26/21 (low, medium, high settings) to 56/32/22 fps in metal. The highest setting didn’t get faster because at that point my _GPU_ is the limiting factor; the middle bucket is where there was the biggest difference because it was most limited on the CPU without the GPU being maxed out.
* The exception is on Mac, where we couldn’t do multiple shadow renders at once in GL 2.1 – with Metal we have this, resulting in a really big FPS increase when scenery shadows are enabled.
“* The exception is on Mac, where we couldn’t do multiple shadow renders at once in GL 2.1 – with Metal we have this, resulting in a really big FPS increase when scenery shadows are enabled.“
Yaaaaaaay! I am really happy about this, as removing the 3D shadows really cuts down on the immersion.
After reading this I’m even more insane to get my hands on this version, I’m running it on a I7-8700K, with 64Gb 3200Mhz of RAM and a RTX 2080 TI, and I’m totally CPU bound today…..
How about AMD GPUs with rubbish Windows OpenGL drivers though? We can expect a jump in performance there right? (Running 3900X and a Radeon VII)
Should be a notable improvement if you’re CPU bound.
Wonderful, thanks for the continued efforts.
Do your general comments for the Mac apply to us Linux SIM users as well?
Please keep up the Linux support, this is the reason I chose X-Plane in the first place!
Those are (in my particular case) wonderful news! Thanks for answering, Ben! After getting that 1660 Super, I know that my main limiting factor is my old (but still capable IMHO) CPU, and this info just made my day!
Hi,
Don’t know if asking this here would be correct !
But will users with the AMD FX series notice any difference ?
Eagerly awaiting 11.50
Rgds.
I had thought we might see a Christmas Day public beta like you did a few years back with 11.20 VR beta. Thanks for taking the time for the blog post. It’s great to read that it’s close. I look forward to trying it and providing feedback. Happy Christmas Ben and the team.
I would have liked to do that but realistically the Vulkan build hasn’t been used by enough people yet to just put it out there – we’re trying to get there as quick as we can.
Speaking of VR, will this initial beta support VR and any improvements in this area?
It does support VR, there are open bugs with VR right now that are not yet fixed, and VR should be smoother.
congratulations to the xplane team. so you mean the vulkan and metal can help xplane run smooth even in 10fps
wow still no reply on my comment
Yes. Even down to 1 fps, it will be a very smooth slideshow.
Thanks for the update.
on my laptop equipped with “GeForce 930M” it has dedicated VRAM 2048 MB DDR3
and according to system information utility of Nvidia control panel it shows:: “total available graphics memory 8139 MB”
My laptop having 12 GB of Ram…
it is not a beefy laptop for gaming i know…
Question is:: How would X-Plane relate to available memory ? does it go only by physical, or it accounts for the for 8139 MB ?
Uh, running X-Plane on this hardware is going to be a mess…Vulkan or Metal. You just don’t have much of anything here. My guess is we count the 2 GB of _real_ VRAM. But the log.txt will actually say what the driver tells us.
(In Vulkan we can tell VRAM from system memory being used by the GPU .- we’ll only render textures from VRAM to protect your FPS.)
These are perfect news. Hopefully you get it stable enough for everyone to test this.
Do you have this performance advantage, you’ve mentioned only in default planes or also in third party aircraft (e. g. Toliss A319)?
My guess is that you’ll see _less_ performance win with third party aircraft – our experience with third party aircraft is that they sometimes contain significant (by our perspective) usage of CPU time; if 30% of your CPU time is being used by a third party add-on we can’t optimize, the benefits you’ll see from our side will be about 30% less dramatic.
If I am currently using mainly two cores (no hyperthreading), with another six sitting at idle, will X-Plane 11.50 use multiple threads efficiently to offload CPU time used by third party aircraft? Will it be beneficial to turn on hyperthreading so that XP can use more than 8 threads? Or are thrid party aircraft slowing down main threads that XP uses?
X-Plane _cannot_ offload third party aircraft CPU work to other cores by itself. Third parties can write their own code to do this, and probably should if their add-on takes a lot of main-thread time; some already do this.
Interesting. Can you list some 3rd party aircraft developers that are currently doing this? Thanks.
I’ve discussed this kind of thing recently with multiple third parties, but I don’t want to name names there because we try to treat what third parties tell us as NDA (regardless of whether they’ve signed one).
Here’s a much older example: Javier and Philipp’s CRJ-200 — if I remember what Philipp told me, the FMS actually runs in a separate _process_ that communicates back to the X-Plane plugin.
Since a separate process is by definition running separate threads, this means it’s in the background and not hurting X-Plaene’s FPS. The other big win is that it’s isolated from X-Plane and all other plugins, so it can’t wreck other plugins and other plugins can’t wreck it.
Hello,
You mention that all textures need to be compressed, that is no problem with DDS, what about NORMAL files? These are currently uncompressed .PNGs, I am asking particularly for aircraft development and updates I will need to make for 11.50 compatibility. Thanks for your great work and dedication to the Sim.
Cheers
Sorry, I should have said: “all textures that can be compressed” – you don’t have to compress normal maps and we won’t do that to you. One of these days we’ll put in BC6 normal compressor or something.
If you are using the normal map for gloss only I strongly recommend a gray-scale PNG with just specularity – it’s 75% smaller.
Thanks for the clarification, good times ahead 🙂
Thanks for the good news about the next beta 11.50. Like a VR user of X Plane i’m very excite to see the improvements of this update. If I’ve understood correctly, in the future X Plane will only use Vulcan and Metal? so third party developers must rebuild or adapt their products to this future paradigm ? we can compare this change with the step from 32 bits to 64 bits…..
It’s not quite like 32-64 bits, because we run 2-d drawing in OpenGL from inside Metal/Vulkan and we are not getting rid of this “bridge” technology.
We are going to support GL mode for the rest of the v11 run; we haven’t made a final decision about future unannounced products. But I think even if we were to be Metal/Vulkan only for the sim, we’d still use GL for the bridge.
– It would be a huge effort for the community to rewrite ALL 2-d panel and UI code in Metal/Vulkan from GL – tons of add-ons would be lost.
– The dev effort would be way worse than just rewriting the add-ons, because dev costs for Metal/Vulkan are way higher than GL.
– Reliability of the sim would get worse due to bugs introduced in third party Metal/Vulkan code.
– It wouldn’t really make anything better; for the purpose of 2-d drawing, GL is fine – in some cases it would be nice to have better written OpenGL, but if the problem is poorly written third party GL code (from non-experts) we can’t expect moving those devs to Vulkan/Metal to help.
Hello there !
Well, this must be the biggest technical update X-Plane has ever had… I think you never have coded a new rendering pipeline since X-Plane has always been OpenGL ; correct me if I’m wrong…
It’s like rebuilding the walls and floors of your house, taking furniture, electricity, plumbing out, then tear down the old structure, building new walls and floors and putting back all the furniture, electricity and plumbing in…
Maybe not the best analogy but it’s an impressive work and a testament to your capabilities and commitment as devs.
Hope you’ve had enough coffee and/or some kind of liquors to go with that long and intensive coding work! Keep up the good work and an happy new year to the team.
This is the way!
As far as I know, X-Plane has been OpenGL since it started using hardware accelerated 3-d. My understanding is that there was a time back in the 90s (XP4? Anyone around from back then) when X-Plane drew non-textured scenery using the CPU to fill in pixels on the screen for a rudimentary “blue side up green side down” world. Back then hardware to do 3-d rendering was quite exotic – when I started my first job back in 98 one of my co-workers had a voodoo2 card (//en.wikipedia.org/wiki/Voodoo2) and this thing was considered both really exotic and really badass. Within a few years, 3-d hardware was everywhere and Austin picked up OpenGL as a way to talk to it on multiple platforms.
Raises hand!
Adding the first Voodoo 1 card to EF2000 was indeed, totally badass. 🙂
Heck, I had 2 Voodoos in an SLI setup! 🙂
Ditto! I had them all – Voodoo 1, 2, Banshee and finally Voodoo 5 before 3dfx messed up.. Glory days:D
My first 3D card was the voodoo2 8M add in card. Loved it, it was kind of revalation.
You can’t forget the first
Congratulations on almost keeping your “promise” this year 😀
Just kidding, looking forward to it. Will be interesting to see the “battle” between X-Plane and MFS this year.
Good luck!
I still have 5 days!
The “Battle” is over before starting for me as MSFS will be a subscription release. I hope you guys never go that way because as a retiree, I will not have the funds to make monthly payments.
FS20 is not going to be subscription. it will be part of Xbox game pass like every other Xbox 1st and 2nd party game a long with select others. the FS20 devs have said it will be single payment option as well.
for example you can buy Forza Horizon 4 for 40 bucks or get it as part of Game pass along with 100 other games for 15 bucks a months
Oh good to know. I don’t like subscriptions. Which is one reason I didn’t get X-Plane mobile. I’ll have to use fs2020 on Xbox as I don’t use Windows pc.
FS20 won’t even be an option for me, unless they had Linux support or it runs well under Wine which is not bloody likely, even from the “new” Microsoft.
Merry Christmas to all and thank you for these news.
Will this “MicroProfile” window be available as a tool/plugin for all (users/developers)?
best regards
//Carsten
Maybe! Sidney and I were discussing that…it might be eye-opening for plugin authors to see how much of the frame time they are taking up. 🙂 .
This would be an amazing diagnostic tool for everyone to have access to.
Is there a good address I can send some whiskey to? Brilliant work. Keep it up Ben.
First off, thank you for posting this info.. My question is this. Will Vulkan fix the RTX stutter issue experienced i 11.41.. Seems like the sim is not optimized for Nvidias latest graphics card series.. Not talking about ray tracing but more the utilizing of VRAM.
I have no idea. I cannot state whether any particular stutter will or will not be fixed. I do not kow what the “RTX stutter” issue is, as there are a ton of different stutters in 11.40.
With that in mind, if you _still_ see a stutter in 11.50 with the Vulkan drivers, you can send us a stutter profile and we can look at it and have a prayer of figuring out what has gone wrong! That’s real different from 11.40.
Thank you Ben and Merry Christmas to you and your family.
What can a user with a bleeding edge computer like RTX2080Ti and core i9/Ryzen 9 expect in increase with this update? a massive FPS increase? 20%?
No idea, but not massive. The NVidia GL drivers were the fastest GL-based drivers, so they show the smallest improvement.
Great update guys, but I just want to say thanks to the whole X-Plane team for your work this year, and Merry Christmas to you all.
Once we get access, what is it that we can help with?
What feedback are you looking for? Just run our normal flights and report any bugs?
Super excited for this.
Any FPS gain is appreciated, especially in VR.
Anyone over there testing VR seen any improvements?
Mostly bug reports – probably the most important thing are:
– Add-on is broken in GL in 11.50 but worked in 11.40 – that’d be surprising and bad.
– GL driver in 11.50 looks different from GL in 11.40.
– Vulkan/Metal driver make rendering artifacts or crash or have bad performance.
Hi Ben. Regarding bug / defect reports, do you use a product like Jira to management reports? Do we have access to whatever you provide? Is there a post somewhere that goes over this, that I may have missed?
Thanks,
Brad
We use Jira internally, and it’s not public; we’ve never found a good way to do this although we are aware of developer’s desire to know what happened to their bug. We go through the same thing with the vendors we deal with (AMD, NV, Intel, Apple, Google, etc.).
Bug reports are routed through help scout, our help desk software, but have their own category so they do appear distinct from tech support requests; we also have automatic linkage between the ticket for the bug report (which is what you hear from us on) and the internal bug report, so things are a lot more automated than they used to be.
We try to get you the internal XPD number of a bug so that if you come at us in six months you can say “hey what about XPD-102041” – we can look that up a lot faster than “hey what about that bug where the clouds had a drawing bug”. Jennifer’s pretty good about listing XPD numbers in the fix notes too so you can know if your bug is fixed definitively.
I put together a brand new system with this “new” X-Plane in mind. I am SO looking forward to trying it out….helping out the devs in my own humble way to get as much an immersion feel to the sim as I can get. I already get 60 FPS + with all my sliders one notch down from max and am excited to see which ones I can crank to max! If I can’t……I don’t mind, I love this sim as it stands! Thanks for all your hard work!
Thank you for bringing this as a v11 update.
Will Vulkan fix the 3D mouse pointer slow down in VR? My GPU suddenly slows to 50% load whenever the VR mouse is visible.
If not, I’ll gladly help you debug it.
I hope so! We were never able to diagnose this bug – it only happens to SOME users and it’s one of those cases where we can’t see what’s in the black box of the driver. We can see into Vulkan so we can grab a frame trace if users see this.
Is is possible to add a keyboard key bind for “reset controller”?
Recently I ran into a issue where X-Plane doesn’t recognize the “trigger” button in both VR controller when using Oculus Link. This is a catch 22 because only way to map it is by using a working VR controller in VR mode!
VR Mouse won’t come up. After many ties VR Mouse eventually showed up and I was able to “reset’ controller and everything is working. There needs to be an alternative to having a dependency like need a working “VR controller” to fix “VR controller”
These are caused by a SteamVR update. Enable betas on SteamVR in Steam to get the fixes early.
That MicroProfile dialog you are using to examine a breakdown of what is going on – is it developed just for Vulkan or is it an existing tool available for us end users to use within our current X-Plane builds? I would like to see what my current build is doing and where as I am expecting to upgrade or replace this current PC and I would like to know whether my CPU or GPU need replacing or both. Thanks for the update, looking great. Regards, Guy.
Well, first it’s a third party open source library that we integrated that’s really fantastic. We added it to the sim as a general purpose tool to get better insight into what X-Plane is doing – we use it in conjunction with Vtune, instruments and a host of GPU profilers to get a complete picture.
I would _not_ expect end users to use it to figure out how to upgrade your machine – it’s really not meant for that.
Be brave and launch already the 11.50 for those more valiants in a link, those brave valiants like Ben, we are courageous and rough enough for blue screens and freezes, be brave Ben. Thanks for all and a really happy new year!.
What an exciting time for all involved! Congrats to you and your team for making things better for us all!
My question is specifically about the zibo 737. I see allot of talk about Arron’s and different types of aircraft. I however, didn’t read or hear anything about the Zibo. I only fly Zibo and occasionally an old DC3, lol. How will the new software help the Zibo, if at all?
Thanks much.
P.S. I have absolutely no affiliation with Zibo or the folks that made it, just a blown away end user. Especially in VR (Mind blown).
I would expect the Zibo to “just work” – 2-d OpenGL custom avionics are emulated, and the rest of the add-on would be unaffected. You’d see higher FPS if you were bottlenecked in the driver on the CPU side.
By the sounds of what your saying Zibo devs will need to update Zibo to run better with Vulcan? I am by no means any expert or even claim to know anything about coding at all, I just love X-Plane and the Zibo 737-800!
I don’t think they will need to change anything. Most aircraft will just work unless the authors have done something _really_ unusual.
That’s fantastic news! Keep up the great work, I’ll be a customer for a while!
I’m surprised as the Vulkan arrived earlier than expected. When identifying performance bottlenecks I wonder whether OpenGL will benefit from it also.
In my view the resource usage of the different sliders was not accurate recently: May CPUs were loaded lighly only, but frame rate suffered. So I had moved some sliders that should add CPU load, but the settings did not.
Ideally I’d like to see the actual resource usage a slider setting causes; so one could really “tune” in the optimal settings (assuming that the resource usage is somewhat constant while scenery and weather changes).
I’m really curious whether 10.50 will eventually deliver a decent frame rate (similar to X-Plane 9) on my hardware.
How are the chances for auto-tuning decent settings (based on CPU type and speed, GFX card and VRAM, RAM available)?
Happy Holidays to the Laminar team. Great to see some swagger start to come back. Can sense some excitement about this release, and can tell from the posts here that either Ben has been hitting the cocktails or he has found his shield again to be patient with this sometimes belligerent community.
As a VR user, I am anxious to see the improvement in smoothness, and hoping to get just enough relief of my CPU to crank MSAA from 2x to 4x to remove the shimmers.
Ben can you give some details on the open VR bugs mentioned above? As Vulkan/Metal is just a checkbox, would you recommend running a completely separate instance for beta testing or is it safe to upgrade main installation (I always keep a backup to roll back if needed)?
We may reach a point where you can just use 11.50 as your normal build with GL as “non-beta” but we’re not there yet. We rewrote a TON of X-Plane code to get here, so we have bugs that are just bugs. For example, crashing in Nimbus KPHX – this was due to a bug in the refactored material handling code inside the OBJ engine…we didn’t catch it because the OBJ in question is probably an authoring mistake that the sim is supposed to safely handle.
What are the FFT results being used for? Water surfaces?
Yeah water waves are FFT based, a la Tessendorf.
you know there ways to do things in real time that dont run at 5fps right like say screen space reflections and cascade shadow maps …. just saying
You have some very interesting ideas about how X-Plane actually renders a frame, and I’m very curious where you are getting them from. Have you ever looked at our shadows? Do you know what cascade shadow maps actually are? Because if you did both, you’d notice that our shadows are in fact using cascade shadow maps. Same goes for your perpetual claim that X-Plane VR renders each eye independently, when in reality we use multiviewport rendering and dispatch both eyes in a single draw call.
I think we can all agree that X-Plane doesn’t deliver AAA game performance, and we are trying to close that gap with our Vulkan and Metal work. And maybe X-Plane is just too opaque to make a good guess on how it draws it frames, but just shouting random buzzwords from SIGGRAPH/GDC talks isn’t all that helpful. Especially when they are things we have already been doing for years.
Well, if it helps to get more info… 😉
Two thoughts about the fail to blurry textures frame rate save, Ben.
1. Can we please have a log.txt message when this happens. That will help when 3rd party devs get complaints from users claiming our product is low quality.
2. Conversion to .DDS could be as simple as dragging the existing PNG’s into X-Grinder, correct?
Thanks for the Christmas present, even if it’s only news of progress at this point!
1. It’ll probably be on-screen. E.g. “x-plane is running out of VRAM…”.
2. Yes.
That will be terrific at the user level, but when I’m reviewing some poor soul’s log.txt that thinks his vision is getting bad and doesn’t notice or doesn’t understand the onscreen message, it would be terrific to see a one-time log entry that tells me, as 3rd party dev, what happened when I cannot see his or her screen. Some users are great with screenies when they see something they do not expect, some are not quite as astute.
I’ve reviewed the X-Grinder and DDSTool docs. It’s way too easy to pre-compress. Thanks for the confirmation!
With Vulcan can we expect houses (or chosen user OBJ-files) to be “hard” for nearby scenery for helicopters) ?
For a plane it doesn’t count a lot, but for helos flying in cities etc it’s a totally different story.
Looking much forward to Vulcan – u still got a few days left of 2019 😀
Vulkan has _no_ impact on the physics engine, scenery authoring decisions, or collision testing.
But while taliking on it: What makes an object “solid” in X-Plane? Most houses, electric wires and trees aren’t, while (it seems) roads are…
There’s an attribute for the various art files indicating which polygons should be hard for physics collisions. So one could create art assets that are “hard” for the physics engine, then you’d have to see if it affects FPS.
My non-expert guess is that checking fir collisions should not need more CPU cycles than casting cockpit shadows. Or can shadows be generated to the GPU while collisions can’t?
For ground traffic there is a “rotation circle” around the plane that other traffic tries not to cross. Why not have a “3D player bubble” to check for collisions? If there’s an object intersecting the bubble, then the software should have a closer look whether there’s an actual collision. One could also imagine having a “flight path tube” instead of a player bubble to check collisions. A ground proximity warning (terrain following mode) could also benefit from that.
For the first part, yes, checking for collisions is a lot more CPU intensive than casting shadows. Shadows are done on the GPU and the CPU just needs to generate some drawing commands for it, it doesn’t even need to examine the polygons. Collision detection is a lot more complicated, especially when it involves very complex bodies (such as aircraft).
Okay, I see..
But still: the physics “desicions” have probably been made with FPS in mind.
Now with Vulkan (not Vulcan, thank you someone) it seems we (some) are getting pretty good FPS in the future.
My question was about whether you would consider to “review” those settings with good FPS in Vulkan?
That also goes for the question of having a monitor for a downpointing “camera” (to see the ground beneath a helicopter)?
The “FLIR solution” is not good enough + not actually showing user implemented OBJ-files.
In other worlds: will there be (at least hope for) seeing “picture-n-picture” eg. showing 2 different things on 2 monitors (or one) ?
(P.S. I am looking forward to Vulkan anyway) 🙂
I’d disagree on the plane comment, it *does* count a lot. Taxying through trees and buildings without losing wings is disconcerting.
(P.S – it’s Vulkan not Vulcan).
Great news, guys! Good job!
How about multiscreen setups, have you tried does Vulcan/Metal improve performance with multiscreen setups? At the moment example three external views (on scenery only mode) does perform pretty badly compared how single screen setup does run. Also FSX did perform much better with multiscreen setup 10 years ago with high level computer at the time compared how x-plane does today with current high level computer there’s quite a lot to catch up.
I’m not expert but I understood that Vulcan does allow using example example multi-core processors more efficently than opengl does allow. So I believe some improvements with performance can be expected on?
Multi-monitor is probably slightly better due to reduced CPU, but it’s not a huge win. Now that we have Vulkan, we are in a position in the future to render two monitors with two cores, something that was not efficiently possible with OpenGL.
Do you think that with 11.50 your standard recommendation for system RAM will increase to 32Gb, given the new memory use methodology? Thanks for your hard work and dedication.
No – the methadology is for VRAM, but we’ve always had a view that more = higher tex res if you don’t have much. I’m not sure on 16 vs 32 GB at this point…the stakes for main memory are lower if you have an SSD.
Actually I think X-Plane 11 should not require more than 16 GB of RAM; if it does, allow some tuning at least to prevent that.
re the 45fps behavior, I am making assumptions and am no expert but..
User: LCD panel can you run at 45htz?
LCD: Sure I can, look this is me doing it. 60/30/60/30
User: Suuure you can. Nice.
Is there a snippet of code in an Nvidia ( what was the other company called again? ) driver or somwhere causing this? No one would create a screen that exposed a resolution that required such a crazy workaround in the screens hardware surely?
Hypothetically.
Any framerates that does not divide into the dispays refresh could be chucked out by X Plane as a temporary solution to this problem. Fun to code too :).
X plane is the best thing for your FPU. Thanks for making it. Making silky smooth stereo3D youtube vids is going to be just the best thing ever. If I could just get a single view for any of my videos….
In the case we see with the saw-tooth 30-60 (when X-Plane can sustain 45) my suspicion is the window manager’s compositor has picked 60 and thus is missing frames. I actually haven’t tried changing the refresh rate of the monitor to 90 to see if we can get 45…it’d be a useful test for the _full screen_ case.
We moved away from exposing refresh rates in the past but perhaps they need to come back. It seems like a weird thing to do in 2019 though since they’re basically fictional.
Maybe you had Vsync on? That would only allow 60, 30, 20, 15, etc. fps.
Nope! That’s the thing that was weird is that vsync was _off_.
Some kind of forced vsync for a window would make sense to prevent tearing. So perhaps an OS issue. If the sim was falling short of 60 that would explain the 30s. Without the MicroProfile you might not have known.
Hi Ben,
In simple terms, how much improved performance can we expect to see with Metal?
-using add ons, third party planes and scenery. I don’t use default global airports.
Performance meaning higher FPS & less stuttering.
Months ago you guys said you’d have metal and vulkan out before years end, technically it is but not in masses. Any eta ?
Anywhere from 0% (if you are GPU bound) to 60%) if you have a ton of CPU and are strictly bound on shadows for max autogen. That 60% is really theoretical – you get that if you get just the right machine and set up just the right scenario to get the max benefit out of the CSM shadows being done in a single pass.
Nice jab Ben Supnik !!
I want to know if xEnviro will work with Vulkan.
I think xEnviro is one of xPlane’s most promising add-ons.
Probably not. If an add-on draws in 3-d, it will not work with Vulkan.
Hi Ben,
Big fan of your dev blog; would be great if you had time for more entries.
Would an add-on that uses the Vulkan layer system work? Thanks.
Regards,
Karl
Oh boy – you mean, like, can you run the validation layer in X-Plane? Or can you use the layer system to hook into what X-Plane is doing?
Side question- why doesn’t VR work on Mac & do you have plans to ?
It will work some day but does not work in VR now. We needed to port to Metal frist to get certain driver features. We haven’t had time to do the rest of the port to SteamVR.
“We haven’t had time to do the rest of the port to SteamVR.”
Does this only apply to Macs? Will SteamVR on PC work with 11.50?
Yes, VR on Windows still runs on 11.50 like it did on 11.40. This is purely for the macOS side.
Bummer. I guess this means there won’t be any point in dusting off my VivePro and trying to hook it up to my new Mac Pro? Is VR on Mac planned for 11.5 or not until some future release?
Hoping Metal support will allow X-Plane to take advantage of all this hardware, because currently even when X-Plane is struggling down into single digit frame rates in LAX or LGA with high settings, my CPU(s) and GPU don’t even seem to be breathing hard; assuming/hoping the bottleneck is OpenGL.
I fly a 3.2GHz i7 32GB 2018 Mac Mini with RX580 8GB eGPU. It cannot run X-Plane above minimums, and I have to avoid major airports.
Will Vulcan unleash my current system, or do I need to trade up to an iMac to get decent performance?
It may be better – we found that eGPUs don’t work with OpenGL because too much of the frame data is stored on the CPU and has to go over the wire to the GPU – that connection isn’t _that_ fast. With vulkan we get more control.
Back in the xplane10 days, some douchebag who shared my internet connection, tried downloading xplane10…. i got a letter in the mail and had to pay a 1500Euro fine. I paid it and brushed it off, it was my fault for letting a douchebag use my internet connection. Ive been loyal to laminar though, even with them concentrating on the mobile version. But im hearing/reading rumors, that xEnviro might not work in 11.50! For me this is the final straw. Ive been waiting for the Vulkan patch since the first announcement of it… and now, literally hours before it is released, they say “Xenviro may not work with it”. Dont care how many more frames i get, i cant go back to signpost clouds. If xEnviro doesnt work with Vulkan, this is how xplane will die for me and i will join the group of people who will stop flying sims till fs2020 comes out. This will be a gamebreaker…. or simbreaker if you will, for me
I am not sure what to tell you, but breaking 3D plugins isn’t an arbitrary decision on our part, but a very much technical one. The sim already has to go through a bunch of hoops to provide support for 2D rendering so that UI and panel drawing works as is, 3D drawing support is literally impossible. Especially the kind where a plugin relies on reading and modifying a bunch of resources that X-Plane loads and creates, by abusing the fact that OpenGL allows this kind of very dynamic behaviour.
This is also not anything new, we have made our compatibility goals public over half a year ago. The good news is, that we aren’t going to stop shipping the OpenGL backend. OpenGL is supported for at least the entire rest of the v11 run, so if your favourite plugin just can’t work without 3D drawing, we aren’t taking anything away from you. You are very welcome to run the sim as it were before and enjoy all of your plugins just like you are today.
But that is the core of the problem. Many xEnviro users had high hopes that Vulcan will improve the performance of that plugin. Now to say it still will work as always, make no sense to use the Vulcan API. No progress had been made at all for xEnviro users.
I am not trying to come off as rude, but this has been known for a long time. The problem is, the kind of invasive behaviour of some plugins just doesn’t work in the new world anymore, and there is nothing that we can do about that. We realize that there is a shortcoming in the SDK here as well, but no SDK changes we can think off allow for this kind of behaviour. OpenGL gave great freedom to developers because it was very dynamic and you could whack it’s state and mutate objects at will and the driver just had to make this work. With Vulkan and Metal, none of this works anymore, because these things are what makes the drivers slow. This puts us between a rock and a hard place, because users do want the performance and stutter improvements that only Vulkan and Metal bring, but they don’t want any OpenGL based plugin to break. Unfortunately, that just doesn’t work. It’s the pro-verbial wanting your cake and eating it too.
I believe we do have a good solution in place to not just whack people and kill off their plugins: On one hand we do support the classical OpenGL backend as is, which means existing plugins will continue to run. We also support a plugin bridge layer where the sim will run a real OpenGL context to provide support for 2D drawing for things such as panels and UI. This supports a good 90% or more of all plugins out there (I haven’t actually run the numbers, and it’d be more like 99% if you want to count scenery).
So, in this case you guys probably need to get weather and lighting up to par yourselves both in OpenGL and in Vulkan. Xenviro might be a controversial plugin, but seriously, billboards of any kind don’t make it any competition already. Please give us a hint if you are looking into this 🙂
The sheer number of people that currently use shader modifier programs should send a clear message to the dev team, that this is a desired feature. Most(some?) understand that VM will break these programs. The fact that they are used by so many should indicate that the default dull hazy coloring of the world in XP is something many users dislike, and then turn to shader modifier programs.
It would be nice if there was a native way, via sliders, or value window inputs, to achieve what these programs currently achieve as an addon.
Shader modification has been very difficult to do since 11.30 when we phased in some of the Vulkan/Metal architecture changes. It was _never_ something we could support.
Whatever we can read from third party add-ons (and my take is not that “X modification is desired” – my take is that “Y feature in the core sim isn’t good enough” but it may be some of column A, some of column B) in practice there isn’t a sane way for us to provide a shader modification architecture.
We are not a game engine like Unity or UE4 and the thing that happen in a UE4 game that make shader authoring possible -totally are the opposite- of what is going on in X-Plane.
I think Sidney has covered this before – things that don’t work in Vulkan (both supported features that still work in GL like 3-d drawing callback) and unsupported hacking (e.g. shaders) don’t work because there isn’t a sane way to do them, not because we want to break add-ons.
All of our development has tried to maximize the compatibility that we can maximize – we structured the work specifically to keep the GL code path working even when the Vulkan path wasn’t going to exist.
“the group of people who will stop flying sims till fs2020 comes out”: Is that the group of people who will re-join X-Plane after FS2020 came out? 😉
Sorry, but you sound a little as a child announcing “If I don’t get XXX, I won’t wash my face any more!”
Yesss.
I have the new 16 MacBook Pro with the mid grade graphics card, and I am actually surprised how well it runs Xplane today. Should I see a big improvement with Metal?
Excellent work Ben, and team!
Thank you!
Happy Christmas and Thanks for your effort with Vulcan!
Not tested our (10+) X-Plane addons with 10.50, still wait a private beta.. So, will discuss/report this later, But I am sure what LR may make developers life more-more easy with API 2D drawing functions. Every (EVERY) developer should create own library for basic drawing before it start create addon. I am sure, LR cam make c++ API what will allow (with better and faster way) do things like API functions/classes for:
– Load png texture and back it ID
– Draw loaded texture with parameters
– Create framebuffer and draw it
– Draw 2D line, draw square, draw circle with input parameters
– Load and draw font with parameters
– and so on.. I can create full list with n/p
All this things already exist in your code and this code is optimized and fast, I am sure. So, please think about this, it really need by many developers, cause everyone need to create own (small or big) c++ library with this functions before start development.
Thanks again and wish you all the best.
Your friend, Eugeny.
Conratulations for the Vulcan/Metal prograss from the x737project team, we are eager to take effort from all the new techniques! I agree to Eugeny’s proposal – an API to draw primitives and handle textures would help developers to speed up their work and release stablea nd future safe addons!
Keep up your great work,
Benedikt
We have definitely thought about this internally, a nice API that supports drawing vector shapes would be very nice, especially for aircraft panel drawing. Now that we have a much clearer idea about what the Vulkan and Metal future (or should I say, present?) looks like, we might come back to further look into this. Unfortunately SDK work is always more complicated than doing things internally, because we’ll have to support whatever quirks we come up with for a long long time. So just bashing out an API on a weekend doesn’t quite cut it.
Well-designed APIs will survive, however. And in the long run you’ll have less work. See PostScript. Most APIs evolve however. Like the Windows API, maybe.
Well said
+10 for this.
Should be in the XP11.5x road map.
Hello Ben, first of all congratulations for the excellent work I would like to know for the public beta we will have to wait for 11.50 or by the beginning of 2020 will we enjoy the benefits?
We’ll release a public beta as soon as we get some bugs fixed.
I like bugs, they are so tiny and adorable, they aren´t bad. Could I have already the 11.50 as it is?. Thanks for the better flight simulator nowadays.
Does Vulkan make much better use of multicore CPUs? The core counts (especially with AMD) are really ramping up, but the per core clock frequency isn’t likely to improve significantly in the future. I’d really like to see it being able to take advantage of high core count CPUs.
I’ve been using X-Plane since v9 since it has Linux support, thanks a lot for the update!
Not on its own. There are more things for which cores matter in the Vulkan build, so more cores will result in better reliability. E.g. if we’re reorganizing VRAM in the background, having a core for that is a win.
Wow, thanks for the fast response! I have a 32 core threadripper with 128G of RAM, (64 cores with hyperthreading) and I’d love to see more of those doing useful work when running the sim.
Looking forward to the update, and Happy New Year to you all!
Are there any plans to give better performance debugging tools to the end user, like showing the CPU usage of individual threads? Then the user (and later the developers) could detect when a thread has too much work to do. The developers could delegate some work to different threads then. OTOH a lightly loaded thread could also be an indicator of lock contention, maybe a consequence of too much delegation…
Even with just 4 cores the load isn’t distributed well now, and recent CPUs will have a lot of cores.
I really appreciated the great work that all the Laminar staff has done in all this time to improve Xplane and that continues to do, but I think this is a consequence of how the competitors now do their part. I think you should have developed this new engine some time ago. Users like us have had serious difficulties running Xplane at its best, compromising either the graphics or the performance of our systems. Anyway thanks for the excellent work you have made making Xplane the best simulator of all time.
The Vulkan and Metal port has been in the making since a good 2 years now (not always full time during that time, but I remember writing the first pieces of code in a hotel in Tokyo back in 2017). It took a lot longer than expected, because it required a massive rewrite of huge parts of the engine. And our goal was to do it right from the get go, not just emulate all the OpenGL stuff we do with Vulkan, because then we’d have the same performance as before (except that instead of relying on the driver to do it all, we’d have to do it ourselves in Vulkan). What I’m trying to say is, the Vulkan and Metal port aren’t a reaction to anything happening elsewhere, it was a reaction to what our users wanted us to do for a long time.
Great news!! Waiting for smoothness and more fps in VR. Keep pushing!! Many thanks. Pimax 5k+ and in 2020 Pimax 8kx.
Currently, the graphics settings page in X-Plane 11 divides its sliders into two parts. The sliders on the right hand side increase CPU utilization, while the sliders on left increase GPU utilization. Will moving to Vulkan change which settings affect the CPU versus the GPU?
No, the divide is approximate but will still roughly hold.
I practically tried all the beta versions, why do you need a private profile for xp 11.50? Very frustrating not being able to help! ..
It’s a private beta with a select group of people so we can find the worst bugs early without getting the same reports 100 times. This is the culmination of 2 years of rewriting huge parts of X-Plane, so we are expecting issues with it (and in fact, the bug reports that we are getting confirm that). Once we are happy with the stability of it and it’s no longer completely on fire, we are going to release a public beta. Same process as with most bigger updates for X-Plane.
Having tried AMD cpus & gpus together and also intel and Nvidia together , its always been that AMD in Xplane is terribly slow. Always been told that AMD has a rubbish OpenGL driver. For example , my last PC was AMD Ryzen 2700x and Vega 64 gpu. It ran awful on Plane but amazing on any other game. Will this Vulkan update make a 3950x/Vega VII sing? Want to build a new PC and want to go all AMD but don’t want to do that if its still going to suck on Plane?
It’ll be significantly better.
It’s like waiting for Christmas all over again! Seriously I’m very excited about the Metal/Vulcan update and looking forward to see how X Plane evolves in the future!
Thanks to the LR team for the efforts, looking forward to the public beta.
Will there be a dataref add-ons can use to check if XP uses Vulkan or OpenGl?
Yes.
I just wonder is it possible to include us into 11.50 test list. We have a number of actual payware and freeware products and need care about their future. I mean: 320 airliner, 330 airliner, X-Life Traffic, Ground Handling, TugMaster, 4 CoPilot plugins for C172/A320/A330/B767, WebCamera Tracker, FollowMe Car and several minor projects. Sure, I trying to contact Jennifer – no answer. Somebody can help with this may be..?
Yes – are you not in the dev-rel program??
Not get any for tests this time. Be useful to take part.
People here know exactly what they are talking about. Just a question from me. Did I understand correct, that Vulcan means less stuttering even with lower frame rates?
It should mean less stuttering in general – lots of code that could stutter (in x-plane and the GL driver) are gone.
I find it disturbing on the sheer number of people who comes here complaining about 3D rendered plugins, xEnviro and shader injection like Reshade.
Laminar and the team responsible for X-Plane are solely responsible for X-Plane, Period!
The fact that they’ve been for two long years rewriting X-Plane, not as a reaction to other sims, should be praised.
The devs and responsible people for this forum and Laminar can’t say what I am about to say, but here it goes.
When buying plugins people should have paid close attention to what changes on X-Plane could do, specially core changes like the API.
When Vulkan came to light some 1 year and a half ago, some people should have been weary on what might happen to their expensive plugins. Also, apart from some study level aircraft, most plugins are a straight rip-off, with a lot of these costing more than the simulator itself, which is being sold at steam for 50 bucks today. Weather injectors that cost 70€, incomplete aircraft that cost more than 100€, so forth and so on, it becomes the buyer responsibility to acknowledge that Laminar changes to X-Plane might break their plugins and Laminar is not the one to take the heat.
I myself am a vanilla user of X-Plane 11, apart from Zibo 738, I haven’t bought anything that would cost more than 1/3 of the Simulator price.
Yes I find X-Plane 11 colors dull, and clouds useless, and I’ve seen what Microsoft has in the oven, still I use X-Plane solely to gaze on Austin’s commitment to the simulator and aerodynamics.
All this to say, congratulations on this two year trip and hopefully my already aging Ryzen CPU can give my GTX 1070 Ti more data to munch on. Thank you for all the effort.
Holding tight for 11.50.
We can’t be surprised that end users like add-ons that appear to work for them and are unconcerned with details like whether the add-on is built on a solid foundation or unsupported hacking.
//www.hyrumslaw.com/
Ironically by keeping the sim stable even for hacking, we encourage it.
Actually I think there are two reasons for people misusing APIs:
1) The API documentation is not complete, misleading, or simply wrong.
2) Users don’t read API documentation.
Personally I think the most terrible thing in programming is when you’ll have to guess what some API parameters actually do, because you cannot get it from the documentation.
That answer is a bit harsh I think?
What dev would expect their users to check the background of a plugin?
And how?
I haven’t seen any email or info in X-Plane 11 either telling me that “3D plugins will simply not work in the future”.
Anyway, I see the backward compability to OpenGL to be the rescue here.
New planes, helicopters, sceneries etc. will still work in X-Plane 11, and “most” people will get the benefits of Vulkan “for free” (vs. waiting and buying X-plane 12 just to get this).
Personally I don’t actually use any 3D plugins..
I just found the answer could have been served otherwise.
Everyone with 3D plugins: remember we still got updates etc as long as X-Plane 11 is developed.
Also it must have been a stressful time for our main programmer so he’s kinda excused for a single “bummer” 😉
Oooh and… Are we there yet?? 😀 😀 *Evil grinn*
Yes, LR is repsonsible for X-Plane, but not “only”. People spending money for add-ons (such is advertised by LR even) do NOT (anybody surprised?) want there add-ons become a waste of money in the next release when they stop working. If it happens, people might go away from LR. (BTW: Who noticed that two airfoils changed in 11.40?)
My most frustrating X-Plane experiences was that X-Plane 8.20 updated from some early-bought X-Plane 8.X DVD was different from an X-Plane 8.20 DVD sold later (it seemed): I had received the DVD set for world scenery as Christmas gift, but could never use it (I still have it), because some library element was missing. Even after contacting LR about that, I got no response. That was very much frustrating!
I think I’ve “seen the light”..
LR are supporting the option for other devs to make “whatever” plugin.
That’s great and better for all than if they closed support for anything they don’t have 100% control of.
But these “other devs” got the full responsablility for making their plugins work with whatever version of X-plane – it’s actually not LRs problem… at all.
If LR want to change their software and it can’t fulfill backward compability with the plugins, it’s just “bad luck” for those who made the plugins – and the buyers.
Sorry Subnik I didn’t understand until now.
Happy New Year all.
Looking forward to Vulkan.. anytime soon now guys! 🙂
Wait – I don’t think that’s entirely accurate.
The officially supported interfaces form a sort of “contract” between LR and third parties. Our side is “we’ll keep these things working the way they used to” and the third parties side is “we’ll use them as intended.”
So for example if you have an add-on that uses 2-d panel drawing callbacks to draw custom EFIS displays, it’s just gonna work in 11.50. The contract says “2-d panel drawing callbacks can be used to draw on the panel using OpenGL” and we have kept that working.
There are a few kinds of add-on problems we are seeing…here are some examples:
1. Skymaxx doesn’t render right in the OpenGL back-end in 11.50 – this is _our_ bug. One of our datarefs is not returning the right values. That’s our bug to fix, we’ll fix it, and things will be…well…fixed.
2. Skymaxx doesn’t render AT ALL in Vulkan. This is because the new Vulkan renderer supports a less generous contract. It supports 2-d drawing like the GL renderer but not 3-d. It isn’t a drop-in replacement for GL. This is _one_ reason why we feel like we can’t drop GL support right now. (Another is that some users won’t have hw that is Vulkan compatible.)
3. X-Vision broke in 11.30 – they were editing our shaders, and our shaders changed…a lot. Shaders were NEVER an API that we supported, they had NO contract. This was a buyer-beware kind of thing.
4. I’ve heard from at least two third party add-ons that develop easily fixable bugs in Vulkan only because they use 3-d drawing callbacks for something OTHER than 3-d. This is definitely a sort of contract violation – 3-d drawing callbacks are for 3-d drawing, not “do whatever you want” – but since they have existed for over a decade unchanged, people have used them for all sorts of things.
(And to put my cards on the table, I was the first plugin developer to mis-use 3-d callbacks … in XSquawkBox back in like 2002.)
In case 1, we expect to fix the bug and in case 4 we expect third parties to bring their code into API compliance, and we expect it won’t be that hard. In case 2 and 3, we expect the add-on to keep working, GL only.
I wonder: Can there be a tool like “plugin verifier” that can detect contract violations? Maybe even as a loadable plugin. Then it could log violations detected.
Probably not. There are some trivial errors we can catch but no one wants to pay a perf price for X-Plane to do deep checking, and in some cases the act of violating the API is what makes things hard to detect.
For example, the API contract on drawing callbacks is “leave GL the way you left it.” But we can’t easily inspect the _entire_ GL state machine to see if something has been left in an altered state.
So ooo oooo happy that Vulcan is on the way – if I could insert an icon of Snoopy dancing it’d be jumping all around the room!
Please use me as a Guinea Pig for Vulcan on Linux – I’m not at all a guru, but I’m very happy to put time into helping make this work if I can. I spend _way_ too much time on X-Plane, so at least it’ll be time put to good use!
Thanks gurus!
Congrats for this big update, i´m looking forward to it.
Will Vulkan help with AA? X-Plane is a fantastic simulator and i´m very happy with it. But the AA handling is a show stopper. Without HDR ON (Day) i´m using a very strong AA setting, 4x SSAA and 8x MSAA via Nvidia Inspector to be happy with the results. I have tested it carefully and noticed that SSAA helps with objects in the distance and MSAA for objects nearby. So during the day i´m using this combination. But this AA combi is fire for every graphic card. During the night, we all know, we need HDR and with HDR we can´t force AA outside X-Plane. In this case i can use 2x SSAA only, more is not possible for FPS reasons. And this is not very nice.
So, will Vulkan change this strange behaviour?
Many thanks for your work!
No. The Vulkan port does not affect what kind of AA we implement, other than allowing you to change AA without restarting.
Hi Ben,
thanks for your answer. Does it mean in detail, that we still can´t use MSAA with HDR ON? If yes, what is the reason for this? Because with many other titles i can use MSAA with HDR ON (As with X-Plane internaly only, not Nvidia Inspector) . MSAA is much more performance friendly as SSAA.
Many thanks
Andreas
So first, the key point to X-Plane in HDR mode is _not_ that it’s HDR…having an HDR surface with MSAA is trivial. The thing that makes it interesting is that X-Plane’s HDR renderer is always a _deferred_ renderer. It’s a two-pass process where-by pixels have their geometry set up first and lighting applied second.
MSAA gives you soft blended edges between polygons by saving multiple final color values per pixel and then blending them later. To get this right in a deferred renderer we’d need:
1. To save more than one value per pixel (e.g 4 for 4x MSAA) for all of position, normals, color, everything we save for the G-Buffer (it’s five full buffers right now).
2. To read all of the samples per pixel (e.g. 4x) and then perform lighting calculations on each one, then blend the final result ourselves (because the MSAA hardware isn’t going to _do_ anything on the lighting pass, since it’s just a once-over-the-screen kind of thing).
If you squint, this looks a _lot_ like 4x SSAA…that is 4x the memory in the G-buffer being written, 4x the memory being read and 4x the lighting calcs.
Now it would still be faster to set render into the G-Buffer, and if you know your graphics hardware you might know that the GPUs have compression options to make MSAA surfaces extra fast, since so often all 4 subsamples show the same stuff. They often have clever ways to get 16x differentiation of surfaces with 4x the color memory – we don’t have access to that.
But color buffers can be compressed now, full stop, something that helps modern cards with 4K surfaces. So we can get that win even in SSAA, e.g. SSAA with compression.
All of this is to say, there might be a win from MSAA vs SSAA in HDR mode (which is deferred) but it might not be the blockbuster win you’d hope for.
In the very long term my view is that the future might not be in really amazing MSAA for deferred rendering, but going to something completely different like a clustered or tiled forward renderer – where basically it’s a normal forward render with an optimized structure to find lights. Those designs have become quite popular in the AAA games and do some useful things:
– efficient with “lots of lights” like HDR
– real hardware MSAA
– handles alpha well (the other achilles heal of deferred renderers).
Off the wall question for owners of Cray Gaming Supercomputers with 6ghz, 100 core CPU’s and GPU’s with 20gb of VRAM… If only uncompressed .png textures are provided, will they still be used as is, or will *everything* be compressed no matter what? A re-read of the compression paragraph seems to suggest that png’s will always be compressed when found – I suspect on aircraft load. Which would make for a rather long load in some cases!
The behavior of 11.50 under ALL settings is the same as 11.40 if the texture setting is anything other than “extreme (uncompressed)”:
– If the texture is eligible for compression (e.g. it’s an aircraft livery and not a panel gauge)
— If it’s a DDS on disk
—-We load the DDS and use it
— otherwise
— We load the PNG and compress it on the fly.
This is what 90% of your users have been doing in 11.40 and what 100% will do in 11.50.
So you will get faster load times and better results if you pre-compress – the offline compressor can take more time to compress better and the sim doesn’t have to do anything. But if you don’t, we’ll compress for you.