It has been almost a month since my last post on Vulkan and the state of development; a lot has happened since then, both for Laminar Research and the world.
COVID-19
First, at this point, no one working for Laminar Research has COVID-19. We have people working on X-Plane in at least six countries, including northern Italy. The team news on Slack as of Tuesday was that everyone is in some degree of lockdown and/or voluntary social distancing, varying by country. Schools in the US are temporarily closed, so both Chris and I have the kids at home.
Being sequestered at home has not affected our internal pace of development because our entire team is distributed and works at home; we have no office to close. This work-at-home pattern started almost twenty years ago when Austin had people like me working on part-time contracts to modify specific parts of the sim – it never made sense to relocate people to South Carolina and open up an office. Being remote also lets us hire people anywhere in the world who have the unique blend of skills we’re looking for.
At this point we haven’t seen any operational issues either; mostly running our business requires that our devs have internet and electricity and that the data centers we use for our cloud servers remain open and operational.
So in summary, we are very fortunate that the new coronavirus is not affecting our development and operations; other industries are paying a high price to stop the spread early. We have several things we are working on right now, and this spring is a critical time in our development schedule.
Vulkan and Metal
Update: I have gone in and changed Vulkan to Vulkan/Metal in a bunch of places – Mac users were confused as to whether we had silently dropped support for Metal at the last minute – we have not!
We are posting developer preview nine to our private testers today; hopefully this will be the last private build before a public beta candidate. We acknowledge we’re reaching public beta much later than we had hoped/wished/anticipated, but we are now aiming for a public Vulkan/Metal beta by the end of March. If you are already rolling your eyes at a public beta date that is less than two weeks away, I don’t blame you; having been this late, it’s on us to post the beta to show progress. With that in mind, I am going to describe what we’ve been doing for the last three months and why it has taken so long to get here.
The Vulkan/Metal public beta is several months later than we had anticipated because of “scope growth” – that’s manager nerd speak for “we added more stuff to it than we originally planned.” Scope growth (adding more features/code/tricks than you originally planned) is one of the big ways that projects miss original deadlines, so the big question is: what did you add and why did you add it?
The first thing we added was better handling of plugin drawing. The rewritten plugin compatibility layer provides better drawing compatibility for more plugins, including weather plugins on Windows. We went with the rewrite mostly because of the level of bugginess we saw with third party add-ons in the early developer previews.
Plugin drawing was definitely a case where we learned how to do a better job from the first version of the feature (plugin compatibility that went into the first private beta); if we had received that second-generation design via time machine we probably could have shipped faster. Adding weather support was pure feature creep–a new thing we didn’t plan on, but something that we thought was worth extra schedule time.
The second thing we added was better handling of texture paging. Once again, this was a feature where we had to rewrite the feature (multiple times in fact!) based on the feedback we got from our testers to really come up with something solid.
Our first generation texture paging around the first private developer preview was very simple: most stuff lived in VRAM, with a little bit of code to move unused stuff out of VRAM. It was a minimalist strategy that let us develop the rest of the sim and worked great on high-end cards. It was clear from day one that it wouldn’t be good enough for public beta.
Our second generation strategy added automatic movement of texture res up and down with VRAM pressure and code to page out textures that weren’t being used. This shipped about half way through the private beta, and was better, but suffered from one fatal flaw: as you turn your head, the stuff behind you isn’t being used. Under heavy memory pressure users would constantly turn their head and see blurry textures that would then “res up”. The results were distracting and unacceptable quality-wise.
We now have finished our third generation strategy: besides automatic texture res control based on VRAM pressure, we now set the relative resolution of non-orthophoto textures by distance to the aircraft. A background task on another core “crawls” the scenery near your aircraft and reevaluates the texture res of nearby scenery constantly, effectively transferring VRAM to where it is needed most. This process is completely transparent; authors do not need to modify scenery in any way for it to work, and since it runs on another core (as does the paging), it does not affect framerate.
In these pictures, you can see the new pager at work. I have parked my aircraft on the ramp at SeaTac and moved the camera across the city, so that the distant autogen (from the pilot’s perspective) is now close and the airport is in the background.
In this first picture, green represents full-res textures, with the next levels down being yellow, then magenta. You can see some nearby autogen down one level and far-off autogen down two levels; the loss of res is put far from the user.
Why is there so much green (full res) near the magenta autogen? Texture reuse. If a texture is used near the user and far from the user, it gets high res because it might be seen up-close.
In this next picture, I artifically lowered my machine from 4 to 1 GB of VRAM using a developer tool. Now you can see magneta autogen close to the airport, yellow even closer, and some really dark green (the next level down) where we had magenta. In other words, everything got a little bit lower res because we were tight on VRAM, but again nearby sceney is prioritized.
It looks like this third strategy is a keeper – it combines the careful management of VRAM to use it where it is most needed with a stable heuristic that isn’t constantly changing, which avoids chaos and unreliable behavior.
So at this point we are just fixing bugs. This is a big step forward for the private beta because past betas were dominated by coding new things, which in turn creates new bugs. At this point we just have to kill bugs off to the point where the build is high enough quality for a public beta.
I cannot promise a particular build number or date will be the public beta full stop, because I do not know yet what other bugs we may find. But I can say that we are in the part of bug fixing where things are getting locked down.
Vulkan is Not the Only Iron In the Fire
A flight simulator is more than its rendering engine (or at least, people tell me that). While we are pushing as hard as we can to get Vulkan and Metal to public beta, we also have several other irons in the fire. This includes new features for mobile, next-gen features for desktop in several feature areas, and even a few extra non-Vulkan/Metal features that have snuck into 11.50. We’ll post more about the mobile and 11.50 features as they become available; the rest is still in stealth mode. Often when the dev blog is quiet, it means we’re working on new things and putting features in the bank; this is the case right now.
Ben,
Just double checking; is the metal beta still on track? I am so glad you all are doing well and everyone is safe.
Yes – Vulkan and Metal are in the same beta.
Thanks for the update Ben, looking forward to try it…
Does my Acer Nitro-5 going to work great with Vulkan?
It has a
GTX1050
icore i7- 7700HQ Processor 2.80GHz
and 8GB RAM is intalled. and i have about 30FPS right now with any aircraft apart from the FFA320 witch has about 14FPS.
Not sure – the 30 fps might be your 1050, depending on what you do with it. And the 14 fps is the 320…we can’t change that.
But does all the stuttering i have when i land go away? Or does the update do nothing to my system?? Because thats a bit sad. I have gotten more and more exited when the moment came closer that maybe this update could get all my stutters away. But if the FPS doesn’t change then i have waited for nothing since it has been announced. Hope it will help just a little bit. Fingers Crossed Is it right that the was announced a update with new sounds to the MD80 Default? Or is it just me? I have a feeling this would probably be one of the bonus features coming with Vulkan i guess.
Marco
Hi Marco,
Stuttering and low fps are _not at all_ the same thing. You _might_ see an improvement in stuttering and no change in FPS.
Stuttering happens when _one_ thing that doesn’t happen very often in the frame takes a long time and slows the frame rate down for a single frame – that’s a stutter.. We have fixed an absolute ton of these, so I’d be shocked if your stuttering isn’t better. With that in mind, if a plugin makes us stutter, we can’t fix that. We have tools in 11.50 to measure this carefully so if you see stuttering _after_ the public beta is available, you can send us a trace of it.
Low framerate happens when some part of your system can’t render the frame very fast _every single frame_. If that is happening because of your CPU, it’s quite likely you’ll see an improvement with the new release. Once again, if a plugin is using up the CPU, we can’t fix that, but we do have new tools to diagnose it.
If your GPU is what is making the frame slow, run at a lower res or get a better graphics card.
Good update thanks Ben 🙂
Do I miss something, but what about OS Mac? (Metal)
I stopped saying Vulkan/Metal everywhere – I sort of assumed everyone knew that we had them together in one big beta.
Thanks! Glad to hear.
Is Metal/Mac users excluded and have to wait even more? I ask because “Vulkan” is used throughout but not “Metal” or “11.50”
Also, is mobile taking away resources from desktop?
First thing: no Mac exclusion, Vulkan and Metal are together.
Second thing: no.
Those colorful houses look beautiful man. I do not wish to ‘let the cat out of the bag’ on any of your wins while doing this impressive rework but. VR shadows, will my hobby of making side by side 3D videos be able to include shadows from 11.50? because at the moment they are pretty broke. Also will the advances you have made in optimizing have implications for mobile technology versions of X Plane. I would not underestimate the value of such fine work. Could mean more sales 🙂 .
Shadows may be more usable than before – I am trying to clean up some of the buggy cases, which have become more buggy under the new back-ends. They are definitely faster in some cases than they used to be for CPU-bound users, especially on Mac.
Re: mobile, we expect to bring all of the work modernizing the graphics layer over to mobile, and run mobile on Metal and Vulkan as well. We have heard anecdotally that the state of Vulkan drivers on Android is not great, but we have not verified that for ourselves yet.
>We have heard anecdotally that the state of Vulkan drivers on Android is not great
I ran a few of the 3dmark vulkan benchmarks on my samsung A70, got about 50% less fps than the gl version for stuff like the physics tests. definitely not ready there yet.
Benchmarks here:
https://benchmarks.ul.com/compare/best-smartphones
That’s not good – the Vulkan driver has to do way less work – if you’re slower than GL, your driver is doing it wrong. 🙂 . We’ve also heard about instability, crashes, etc.
Thank you for the update, I’m looking forward to taking the beta for a spin as soon as it’s posted.
Telework is also a beautiful thing. I could go on a long-winded rant about the benefits of mass telework in industries where it’s feasible to take advantage of it, but suffice it to say that I’ve been enjoying those benefits for years. It sounds like y’all have as well.
Everyone please stay safe, maintain your social distancing, and stay healthy!
Keep chipping away guys, you’re doing fine
Thanks for the update, I’ve been refreshing this page more than the Coronavirus news pages. Speaking of which, hope you all stay safe, and don’t forget to wash your hands after every commit! 🙂
I wash my hands of every commit I make. 😉
git commit -a -m “This was not my fault; It was Austin’s idea…”
LOL!!
Tyler, would you please confirm if the dashboard is still updated daily? Some of the data have never changed in months.
I wish you the best luck you can get and I know you are doing a great job!
Observation: For the desktop Xplane 11.50, you could add seasons (Autumn, Winter, Spring, Summer) if you didn’t do it yet. That would be awesome and wouldn’t be needed complicated-to-install add ons.
Don’t take this as a comparison, but I remember flying with the FSX Demo version years ago, and there was actually a menu where you could select the day of the year and the season.
Also, hydroplane/seaplane handling could be improved (planes on water, when stopped, tend to start moving at circles.
Despite these observations, I think X Plane is “The” Flight Simulator, at least for me.
Every milestone is another stone
Thanks for the great update and insight.
About Vulkan and its memory optimization, are you making use of :
https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator
Can’t wait for next update.. until then, eating orange and working from home.
Yes, we (and a ton of other games) use VMA – you can see Sidney’s pull requests on github as he has worked on it. VMA and its author are both fantastic.
Quote:
That’s the biggest contribution to the library I got so far! I’m willing to upstream your code to the library and also work on it (subject to my time constraints) as decent defragmentation is a very needed feature. Right now I plan to release VMA version 2.3.0 as-is in December 2019, but this defragmentation can become a big thing for the next release.
I’m curious what’s your use case. Are you developing a game or some other real-time, interactive graphics application? For which platforms? It will be great if your defragmentation implementation is field-tested in a real large scale app before it gets to the library. Designing API for it is also better approached from user’s perspective, thinking about what API would be convenient to use in the app.
unQuote
Wow.. frankly before i went on reading the thread on the pull request.. i was having a feeling that the use-case of xplane vulkan port and its inherent requirement for VRAM better managed resource would beat the hell of VMA ..
Now having read through the pull request (and thanks for highlighting about it) i really laughed … and was actually flabbergasted about how far the effort have gone …
Whereby the Laminar Team had gone to Mars to ensure their implementation of Vulkan is a FIRST-CLASS approach (we know not all developers follow best practices) .. The issue of Potential Stutter while doing memory defragmentation using the legacy VMA algorithm is a real example… Sidney did not put his flag down and surrender, and fought his use case to get the last performance squeeze out of the VULKAN Port Project and ensure no more road-bumps (stutter causes)… that rat was nailed…
It was a funny when A. Sawicki predicted the importance and significance of that pull request… at first he did not know what if facing him ahead.. but he was right to say that he expected to have a proper use-case that would justify the effort and attain tangible fruits… i guess he expected to have some sort of demo code or something ..
Here comes the funny part .. whereas sydney throw at him a full-blown planet-scale texture-thirsty professional flight sim that is out there to burn the best out of the Vulkan engine.
no other (ahem… game) has ever gone that far …and A. sawicki could have not found a better real-world use-case than this… the gentleman really liked it and gave his best commitment and attention.
its X-plane dude, no kidding here, and the massage is:
* yes we need better and more efficient memory management
* but we will never settle on anything less than a silk smooth performance-cleared implementation that is done right.
From 6.61 GB (before defrag) down to 5.81 GB (Post Defrag and Compacting) with say average yield of 12% of VRAM re-declaration through VMA is no doubt a very great achievement.
From one side, X-plane is doing its own memory shuffling and swapping of textures, hand to hand with a smart memory defragmentation library .. i dont think things can get better…
VMA and the pull requests give app developers a peek into the complexity of what used to be a driver level problem. It’s easy for developers to rant about crappy perf out of the OpenGL driver, until we try to solve those problems ourselves. Adam’s been fantastic, but X-Plane really is a brutal stress test:
– Absolutely no room for pauses, no level loads, everything has to be real time.
– Big levels with tons of memory use.
– Memory requests coming and going in very unpredictable patterns from third party content.
Good news, great job!
It sounds like the new VRAM management will be great for VR users that moves the head around more than flat screen pilots. Perhaps we will get rid of the “head turning stutters” for good?
Huge thanks!!!
Head turn stutters: I hope so – unlike with GL, we don’t do any blocking on-the-fly loading for things revealed by a head-turn. The blurries in gen-2 paging were noticeable even without VR, just not as much so.
Great update, and thanks for the tranparency! Keep safe!
Any update on the Metal?
X-Plane is still playable on my MBP 2012. But I really want to surf and shred some clouds…
Cheers!
Thanks guys for the great update, appreciated as always 🙂
Thank you so much!! This is great news! Be safe and thank you for the update!
Hi there, can’t wait for Vulkan! Just a quick question, will all my scenery, libraries, aircraft and plugins need to be updated when Vulkan support is out?
Thanks!
A few of the plugins, maybe – we’ve seen cases where developers have misused the SDK and might need to correct their ways. Scenery no, aircraft, depends on the plugin inside the aircraft but hopefully mostly no.
Great, thanks! What performance difference would I see on an RX 580?
I would guess not a lot.
My advice – upgrade to a 5700XT (twice the speed) or wait for Navi 20 based cards.
I can’t think of a better way to practice social distancing. X-plane will be an excellent escape from confinement!
Ben, and team excellent update on this.
So excited… will this new core paging system help for the majority of us using Ortho Imagery?
You mentioned non-ortho in your sentence?
xEnviro finally!
New paging is orthogonal to orthos – orthos have their own paging policy – have for years – that take advantage of the orthos being tagged with location.
I have some cases when using ortho that a tile will stay blank for a while. I am using file shortcuts for most of my ortho on a diff drive. But I have seen this even on orbx scenery on the same drive. Have you done any testing with Vulkan using ortho like orbx true earth or forkboy ortho?
We do test with Orbx scenery packs.
Thanks for some good news about Vulkan, including texture paging. If the following annoying defects can be addressed as the next highest priority, XP will be in better shape to fight MSFS:
1. Fix Sudden weather/cloud redraws (XP should know weather in 250+ mile radius, smooth the transitions in a background thread, well in advance)
2. Ugly looking cardboard trees which have terrible color fading in the evening (can we at least fix the color as a “minimum”).
3. Antialiasing and Reflections code as just bad as 11.00 (enough said)
4. Shadows need rework and/or optimization (even applying the “hacks” it still ain’t particularly good).
5. Better shaders and HDR (add grass shaders by default. Let it be open to the community for improvements)
6. Level of Detail => Let it be configurable, the height above ground to Draw: cars, autogen, buildings, trees.
Greazer.
Looking forward to this but more importantly looking forward to the ‘other irons in the fire’ as I really want XP to remain competitive with the upcoming MSFS. Also, Military/Naval Ops could certainly use some love.
Excellent update Ben! Typically in game engines the level of detail is determined in relation to the camera position. It is understandable that in your application this reference point should be the aircraft instead. For those who like to record flights from external view cameras (and the level of detail being determined by the aircraft), won’t this texture swapping be noticeable when for instance recording a video from the tower and the approaching aircraft is 5 miles out?
Or has your example been set up to demonstrate the texture swapping in relation to the “object of interest” where it can ultimately the aircraft or camera?
X-Plane has a two-tier system. Calculations that can be done in real time are done off of the camera – this includes OBJ/LOD selection and culling. But operations that have long latency (e.g. they take several frames to complete) run off of the aircraft to ensure that they don’t get thrashed by rapid camera movement.
While the texture res is the newest version of this, orthophoto texture res and autogen build-up have both used the aircraft as the anchor point for _years_. So the areas where you might see low res – they’re already low res orthos and missing houses too. Fortunately this tends to happen over a reasonably significant distance. But if you want to shoot a movie, take the aircraft with you, don’t just leave it at the hanger and wander off over 100 km.
Awesome, that makes sense. Thanks for the explanation Ben.
About shooting movies, (just a thought) …
Would it be better to consider “the camera” as the center of the world, rather than the airplane itself. for most of the time the camera is inside the airplane or just around it (as in external flyby views)..
No. See my previous comments.
Yep – got it well this time – you are absolutely right. it does make full send to decouple the tiers based on processing time.
hangAr is for Airplanes
hangEr is for Everything Else
INCORRECT!!!!
HangARRRRR is for PIRATES!
Let’s pick some nits 🙂
Hangar is for *Aeroplanes*
Right, this is what I wanted to ask. In my mind, it makes more sense to decide on what is high/low res based on the location of the camera, instead of the location of the aircraft.
But if we are talking about differences of hundreds of kms, it doesn’t really matter. The point is that it would be nice to be able to make a video where the “camera” is pretending to be a spotter on the opposite of the runway, while the plane is coming in.
PS: Why on Earth Ben is “speaking” in kms instead of miles, I have no idea ^_^
Cheers, and stay safe, guys.
The sim is metric. I’m a stubborn American and like our goofy units, but we’re not savages. 🙂
Re: camera vs aircraft, the camera is not suitable for paging. But the distances over which paging happens are large enough that you can absolutely make a video fo the plane landing from the other side of the runway and not have res problems. (If you do have res problems, it’s because you’ve done something silly with your hardware, like try to run a Careando plane with Orbx on a 1 GB system in HDR at 4K.)
So if im understanding, will this try to if not prevent your GPU usage from hitting about 95%+ usage to help maintain a optimal frame rate what you mean really by lowering farther res to increase closer resolutions?
Also will aircraft textures be a maximized quality with the texture paging function?
We are talking about allocation of VRAM on your GPU. Yes, we try not to run right to 100%, totally full – if we did, then when a DSF load happened, boom, the whole system would blow up. So we have to always leave a little bit of head room for spikes. (Crash the airplane – particle explosion – that’s a spike, we need more VRAM. They can happen suddenly, at least when I fly. 🙂
The idea is that _if_ you are budget constrained, e.g. for your given texture slider choice and scenery and location, your card has less VRAM than we need, we prioritize near things over far things. The aircraft is highly prioritized – it is at the center of your location, by definition, and it still has its +1 res boost compared to other parts of the scenery in the UI.
Hi Ben,
a lot of focused was on what to do when vram gets low. For people who have 16GB or 24GB of VRAM.. is there still benefit when you dont have to move anything out and can e.g. benefit from the full HBM speed?
More is better – if we can just put everything in VRAM, it’s less background work, less bus traffic, more killing power. We definitely have not made 4 GB as be as good as 16 GB.
It seems that all structures in the scenery gets same drawing distance. In real life, bigger structure gets longer drawing distance than smaller one. For saving some frame rates, how about giving lowest drawing distance to autogen buildings which are mostly small houses and multi story buildings while downtown structures like skyscrapers get longer drawing distance?
You’re on to something here, but it’s not quite that simple. The question is _not_ how big the mesh is in world space – it’s how big the pixels of the texture are, when mapped onto those structures.
So if your building is a tall sky scraper but it’s mapped with a texture that repeats, so that the details are really fine, we can still get away with a derez . the max res wasn’t going to be used from far away anyway. But if the building is big and has a low res texture that covers the whole thing (e.g. the texture is _stretched_), then you might see the problem.
We don’t know the pixel density of the non-orthophotos…this makes the new system a little less optimal than orhtophotos, where we get a lot of meta-data. But in practice, I think it will work out okay – I haven’t seen cases where people use extremely low-density textures for super-far-away stuff.
Is this the case that should be covered by alternate object LODs?
Is there a tool to tell you if object libraries have alternate LODs?
It feels like so much scenery could have 1×1 pixel textures per-face for a lot of their screen time at distance.
Out of interest, how does the texture-paging work with the mip-map system?
Texture paging is orthogonal to mip-maps – all textures that we use on 3-d meshes have mipmaps; paging them down to a lower res basically cuts down the top res, resulting in a smaller mip-tree.
Back when we were developing the v10 autogen system, Alex Gifford had the notion of paging directive for scenery e.g. based on altitude. We may add that some day. This would allow us to have very low res for airport clutter when in cruise.
I think this post is rather about geometry LOD, not texture resolution. So its a bit off topic here …
All objects, facades, lines, nearly all items in the X-plane scenery system do define their own LOD distances and they do vary with size, a lot. So its up to the authors of the art asset to set this up as desired. The default library items certainly do have very distinguished LOD distances.
And Ben will surely chime in, but with the vulkan/metal backends this geometry LOD system is essentially not changing at all from what its been in openGl already for quite a while.
hello and thank you for this explanation. we are confirmed at home so a lot of time on Xplane and AC3D
Thanks Ben for this update (I too check this page twice daily for the latest news).
I hope that this new resolution swapping doesn’t re-create a scenario we all experienced in FS commonly known as “the blurries”!
Is there a Laminar “wish list” on the site?
The growth in use of the internal network for multiplayer sessions, which I know is an unfinished part of X-Plane11, requires a few simple tweaks to make practically perfect. Not a tricky task I feel for any data exchange programmer.
Best wishes, stay safe.
There’s no wish list – that doesn’t stop people from telling us what they think in the comments. 🙂
“This process is completely transparent; authors do not need to modify scenery in any way for it to work, and since it runs on another core (as does the paging), it does not affect framerate.”
Woah, that’s already something that couldn’t have been done with OpenGL.¨¨
So – on very top of my wish list is an option for having a camera “outside” a helicopter, showing the ground beneath (in cockpit mode) ( you might have seen this wish from me before 😀 )
Could I hope that yet another core could make this possible?
It would open so many options for mission improvements for helicopter pilots, who now have to both control the heli and try to see what is happening when they operate a sling load, SAR and other types of missions that makes helicopter flying even greater.
Please?? 🙂 ´
Regards
Great to get the update, Ben! You all keep yourselves safe.
Will the Vulkan / Meral version be compatible with the VR function, in addition for oculus rifts?
Vulkan will be compatible with all of the head sets we already supported in 11.41. We do not yet have VR for Metal on OS X – VR is possible under metal but we still have to write a little bit of glue code. I do not expect we’ll have OS X VR in 11.50 – we can’t add more stuff to 11.50 at this point, it’s already late.
Is there even support for VR in OS X? I switched from Mac to Windows a couple years ago _only_ because of X-Plane and VR. I’d really like to come back to the light one day…
Not yet.
As usual, very informative. Take your time to get it our right.
Hi, really looking forward to 11.5. Will steam users get access to the beta at tehsame time or at a later date? thanks
Steam will be available within 24-48 hours – basically if the beta isn’t dead, it will be on Steam. We modified our installer-building scripts to build the Steam and LR betas at the same time, so we can just hit “live” on Steam as soon as we know the beta isn’t crashing. If you’re a steam user and you’d like super-early access (e.g. getting untested betas at the same time as the LR users) we can arrange that.
I would love that and provide feedback. How can I apply?
Hi Ben,
Thanks much for this fantastic update. My older PC will be thrilled by the 11.5 update. I’m running on an i7-3770K and a GTX1070 eVGA graphics card. Not a slouch really but the i9’s with RTX’s blow the doors off of it.
I’d be happy to get untested betas at the same time as the LR users so please arrange that. 🙂
All the best and stay safe.
I’m Steam users, and I just die of envy looking at LR beta users having the first try, can we get it at the same time? even untested, we can roll back to 11.41 easily if we opt out of beta in steam. Thanks!
Hello! Thanks for keeping us Up-to-Date on Vulkan. I have a small question:
Will Vulkan improve performance on AMD Graphicscards? Thanks
Yes, by a noticeable amount!
Many are hoping for that…
Glad everyone is healthy and safe number 1
Number 2 will be seeing changes to water like better waves and colors of water? I fly a lot in the Bahamas and would love to see more realistic water when flying like I saw in msf2020.
In your blog link. The blog states
“Our plan is to have detailed guidance on what technique is best for developers by the time we are ready for public beta.”
Is that still planned? Any best practices to help us not misuse the API. Looking forward to this beta.
Yes – I have some rough drafts and notes written that I need to clean up.
Thank You so much, Ben, for this long awaited post, which acts like anti coronavirus drug.
Hello
SLI mode will be possible (2 graphic cards) ?
No.
Thanks for the update, looking forward for the update.
Greetings from the Czech Republic
1. I want to wish the whole team a lot of Health .. and I have two wishes: please adjust the aerotow ,so that the towing plane will fly to the left or right corner not just straight. Then I would welcome from the camera-tower point of view to make the sound longer to hear. Thank you very much
The length of the sound should take the wind direction in consideration!
Thank you guys for all your hard dedicated work. Stay healthy and keep family close 🙂
Year 2020 is destined to be a turning point in the graphics industry due to modernized API’s and new Next-Gen Hardware soon to be released from nVidia and AMD…
Microsoft is releasing Directx 12.2 Ultimate (https://youtu.be/QvIXvF6r–A)
with a bit of research, we find that the newly introduced features in that iteration do exist in Vulkan with counterpart extensions.
For example, today 20-March-2020 Khronos has released Ray Tracing provisional extensions for Vulkan 🙂
it is not Ray-Tracing that i refer (today RESHADE with RT is achieving good results)- But really i intend to focus on other interesting features that can give a performance boost of 15% – such as Variable Rate Shading and Mesh Shading.
These are sure having their Vulkan counterpart (Namely in Vulkan 1.12) https://www.anandtech.com/show/15401/vulkan-12-specification-released
I hope the development team to capitalize on the best and latest features that Vulkan has to offer out-of-the-box, and to seamlessly incorporate and activate these features in the rendering engine as crucial further performance optimizations techniques – i think this can be done seamlessly.
In short, i perceive that we are just at the beginning by having 11.50 as a solid port foundation for what is next to come and hope to have the new adaptive enhancements revisited through out 11.5x iterations.
Why i thing that “Variable Rate Shading” (https://youtu.be/d1zoGmhVB1U) is very important for the Flight Simulator use-case ?
The expected increase in performance can be up to 150%
Usability Scenarios
——————————
– During Take Off and Go Around (TOGO)
– Touch-and-go landing (TGL)
– Final Approach Leg (FAL) ‘i came up with that :P’
– Flying by visual flight rules (VFR)
The common denominator in these above scenarios is that the ELEMENT of SPEED and Drop of Frames is more felt …. due to usual Heavy Airport Scenery …etc..
This drop of FPS at these most critical moments of the Flight Sim hits badly on the immersion on flat screen, let alone for VR.
As the Airplane accelerates to V1 – their is no need to make the GPU busy rendering every pixel on the asphalt – and surrounding buildings or trees …
Better frame-rate during these scenarios is also crucial for the pilot to better feel the heavy plane physical reactions and vibrations and learn around them … especially with upset weather..
Further in future, VRS can pave way to use better alternative to cardboard trees, as well as reflections on water bodies nearby the airplane …
You people ROCK! 🙂
Greetings
Matthias from Simflight.nl:
https://www.simflight.nl/2020/03/20/74634/
Keep up great work guys.
The pics of the houses remind of the discussions I used to have with my dad when I’d go to check on him and he’d be watching TV. Everything on the screen was red and green. “What’s wrong with it?” he’d ask. “Dad,” I’d say, “you do know that ‘color TV’ doesn’t just mean any color?”
Also, reading all the discussions about programming is as it used to be when as a kid I would read Scientific American. There were articles that I didn’t understand but that registered in my brain as “That is way cool.”
Hi Guys, Hope you release 11.50 soon as i am running out of things to do being locked up inside.
Thanks
So how much drinking was partaken the last month or so, …did you all hit the bottle?
Who even cares anymore. This time next year no one will even be playing Xplane as everybody will have already uninstalled it for MFS. Go work on your mobile app some more.
Chill dude 🙂
Go playing MFS.
I will fly X-Plane 🙂
40% of the user base cannot even run MFS. And a fairy percentage of the Win user base has too much invested in XP to switch.
If you are referring to the combined mac+linux user contingent, I think it’s more like 30% at best, not 40%. Unless there’s another issue – I haven’t seen system requirements from MS.
Mac has actually been rising over the last year. Latest numbers are ~35% Mac, 1% Linux, 64% Windows.
I stand corrected!!!!!!
First of all X-plane is not a game it is a Flight Simulator.
After reading your post I suggest you to buy a PS5 or Xbox, they’ve made for you
Do you mean Rail simulator 2020? 😉
Talk for yourself ”mate”! It’s very arrogant to say you know what we all will do next year! yes i love the upcoming flightsimulator also (I am a ALPHA tester from day one)…………..BUT i will ALWAYS support X-Plane! It’s an amazing simulator and it always will be, I’m sure the next gen of X-Plane will be amazing to! So again ”speak for yourself!” and don’t be arrogant!
greetings
Matthias
The NDA says explicitly that you shouldn’t talk about it if you’re part of the testing team. ;D
How rude. Cheers.
Excitement is growing for sure. Great work through these tough times.
Any plans to look into VRSS for VR optimization? Seems like that would be a huge benefit in getting those pesky VR frames!
VRSS – yes, not for 11.50 but it’s definitely something we think will be useful for VR and other things, and it’s available in a lot of places.
Great! Thanks Ben
great
Looking very much forward to VRSS. Thks Ben for good news on this.
Great to hear you will look into VRSS. What about foveated rendering or DLSS? All improvement will be more fps and better visuals.
How many cores will be the best? 4, 6, 8 or more? RAM and VRAM?
Many thanks, take care and keep pushing.
That was my next question! DLSS 2.0! Looks very promising.
yeah DLSS 2.0 would huge and it no longer needs training per game
As we all welcome and love to see every new graphics technique being implemented, i wanted to highlight my perspective that DLSS is apparenlty not effieicnt for scaling of readable text … think of cockpit being rendered in 1920×1080 resolution, many of the text labels on the cockpit will not be readable unless you zoom unto it –
Comparing to a resolution of 1440p, where text letters are rendered with better pixel density … i would envisage a a more usable and practical scenario of applying DLSS on a native resolution of 1440p scaled to 4k rather than starting with a resolution of 1080p scaled to 4k.
The DLSS is great for scaling “NON-LOW-RES TEXT” AND/OR OTHER GRAPHICS, even if starting with 1080p as baseline reslution.
Finally, it is so far vendor-locked with Nvidia – and linked with Ray-Tracing.
AMD has image sharpening that is not linked with Ray-Tracing..
Read more:
https://www.digitaltrends.com/computing/amd-radeon-image-sharpening-dlss-ray-tracing-e3-2019/
While we hope to enable all the above features, i think it is better to give priority to other non-vendor-locked performance capitalization techniques … such as “Variable Rate Shading”..
I hope that soon users will be able to toggle on/off these features through the Graphics Setting Screen.
DLSS 2.0 solves all of that and its still faster if you havent seen the latest video on it https://www.youtube.com/watch?v=0X1RtXCvPFQ
But DLSS is vendor dependent, isn’t it?
Not only is it vendor dependent, but it also exclusive to Turing cards. So it’s not available on a majority of cards that X-Plane runs on.
Is to day the day ?? 😛
No
You say the team are well use to working remotely and from their home base, but what, if any, procedures have you in place to stop the playing of HL Alyx?
Simple – there’s always way too much to do, so if anyone slacks off they are instantly buried in an avalanche from hell. 🙂
Push it out, we’re all at home.
Hi all.
I’ve been lurking around the blog and never had the courage of asking, but today is the day! How do you, greate devs, test your software? Do you have Unit tests, Regression tests and so one? As a dev myself, I always wonder how to apply these patterns to game development.
Not very well! 😉
We have a few things:
– There is a catch2 unit tests cover some of the low level code. The auto-build system runs this routinely.
– We have a scripting system that can run automatic tests and verify things, take screenshots, etc. – we have a pile of random tests for that, and Jennifer has a farm of machines that can run these.
– We have some longer acceptance tests that we can compile the sim to run to test whole subsystems.
– Jennifer has some tests she runs manually with documented procedures – we try to move those to automation when we can.
– We collect bug reports from users.
So it’s a little of this, a little of that – our main concerns tend to be coverage – it’s a big complex sim, and add-ons can do an almost unlimited combination of things.
Thanks for the explanation, Ben.
It’s nice to know that i’m not so off the chart in terms of testing my games and apps.
So what you’re saying, is that Jennifer is the most important member of your team. Got it. 🙂
So maybe today? First time poster, long time lurker here. Maybe my post will be the lucky one that releases this into the wild and gives us all hope in a time of remote working and going crazy stuck inside…
I’m mainly interested in the particle system gains from Vulkan, particles can quickly reduce FPS.
Is there any data showing how well particles scale with Vulkan?
I have a feeling is either going to be Friday or Monday
Wasn’t Friday….. Sunday is April Fool’s Day so – lets hope 😉
Hi Ben and thank you for your work.
Does my MacBook Pro 15’ 2019 (i9, up to 5.0 GHz, 8 cores, 32 gigabytes of RAM, 1 tera SSD, Intel UHD Graphics 630 and AMD Radeon Pro Vega 20) will possibly work with Metal?
Thank you again.
Nino
If yours doesn’t work; Yikes – nobody on earth can 🙂
Per Apple’s own page on Metal (https://developer.apple.com/documentation/metal) any Mac running running macOS 10.11 or greater will be able to run software using Metal.
Are we there yet?
We are closely following up on the great developments for alpha X-Enviro 1.14 which is making use of the “OpenGL-based weather/cloud plugins from inside a Vulkan render”…
https://s3.us-east-2.amazonaws.com/thresholdforum/arn%3Aaws%3As3%3A%3A%3Athresholdforum/monthly_2020_03/1185466560_2020-03-2708_28_21-unknown.png(25601080).png.8f369b0c6caf80c602db340d04868706.png
Above Snapshot for X-enviro showing new cloud on cloud shadows…
My question::
Are the “Opengl 3d-drawing calls” through Vulkan processed through a separate CPU thread asynchronously? and if not – could it be made possible to make happen?
This would offload the main thread and probably could allocate a separate free core for the task to further juice more performance headroom.
Best Regards
Those GL calls are not on a separate thread and realistically they cannot efficiently be – GL drivers typically have internal locks. And the SDK isn’t threaded.
But also, their add-on should not be CPU/thread-bound; if it is the way to fix that is to use more _memory writes_ and less function calls (e.g. an AZDO design). And those memory writes can be moved to worker threads in GL 4 (available in all drivers that support Vulkan). Writing the add-on via memory writes and not function calls is a necessary precursor to using Vulkan, which is why we didn’t consider native Vulkan plugin drawing a must-have…that code would have to be AZDO + a driver port, and the AZDO part would fix perf.
Thanks always for the insight.
I surely dont want to load the thread with radical expensive ideas.
Wow, i just finished watching a video on approaching zero overhead (https://www.youtube.com/watch?v=K70QbvzB6II) was really insightful.
One more thing that captured my attention is (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/chap33.html#deferred-host-operations)
Do you percieve Vulkan’s “Deferred-Host-Operations” as useful approach which can utilized as part of the pipeline in future…
Back in my mind, i theoretically think of whole weather system as something that should be decoupled from the whole sim processing-stream-wise as efficiency goals as possible.
Thanks again Ben for taking part of your precious time to answer these ideas and clarify about them. (i will not bother further except after having next major update 🙂
I don’t see deferred host operations as useful. Since the API doesn’t provide strong guarantees about when something is deferred, it can’t be used to eliminate stutters, and because it doesn’t make any guarantees about where the work is done, it makes it hard for the app to schedule the thread. I don’t see a case where this is better than the app using worker threads like we do.
Thanks Ben for a great post. To the extent that I understand it, it sounds like marvellous magic. Stay safe and well to all the team. Cheers.
Wednesday is April Fools Day – Has my vote 😉
There is actually an internal discussion about whether releasing the Vulkan on 4/1 is okay….
A win win situation for LR, if the 11.50 Vulkan launch goes belly up, just claim it was all an April fool, if as expected that it runs without any major problems, then put your feet up and drink all of Austin’s expensive whiskey bottles dry as a celebration (if he has any left?)
Just to be safe, I suggest 3/29.
From an IT guy, this is totally the time to yolo into production 🙂 🙂 🙂
Release the Kraken…. er sorry Vulkan!
Technically, it means “Release the monster”
It’s a phrase for letting all hell break loose.
We have no chance of seeing it now Ben 😉
Any heads-up before the release? Like 24 or 12 h before so we can clean our schedule.
Ben,
Thanks for your hard work.
Will Vulkan / Metal optimization have a positive impact on scenario / X-Plane load times? I’m not a professional developer, but with paging I think X-Plane load times should be faster, right?
Thanks for the reply.
Good health!
No – unfortunately in beta 1, load time is going to be _worse_.
The reason load time is worse is that under OpenGL, a lot of loading and prep was done “just in time” (either by us OR the driver) mid-flight, causing stutters.
Now the sim is like a prepper, compiling a shader for EVERY contingency up front.
Try this: in 1141, start at night cold and dark with HDR off. Turn on the aircraft battery. Then the landing light. Notice the stutters? That’s the specializations of the terrain uber-shader being built on the fly the first time they’re used.
In Metal/Vulkan, ALL of that is done up front. Clouds or no clouds, Shadows or no shadows (cuz night). Landing light or not. I could go on.
Anyway, in b1, you eat that loading cost – it’s _not_ that bad the second time you load, but on first load it can be several minutes.
I expect that during beta we’ll find ways to cut those times down, by doing more compiling up front and by removing some unused shader combinations. But we’re not going to hold public beta for it – it’s just a beta, not the final release.
We _do_ get some small benefit from Metal/Vulkan in that everything can be _fully parallel_, e.g. multi-core, which is useful!. But we have seen what appears to be locks inside the driver for shader loading, something we still need to dig into so we can report it to the driver guys. And scenery oad was already fairly parallel under OpenGL and the lock time wasn’t a huge issue.
When does the public beta come out I am so excited and can not wait!