As I announced in my previous post, X-Plane 11.50, featuring native Vulkan and Metal driver support, is in a private beta made up of people in our dev-rel program (E.g. third party developers). We’ve gotten some really good bug reports from them – the reports are good, not the bugs – and based on that, it’s clear that 11.50 will not be ready to go public this year (meaning tomorrow).
This is disappointing to us – we burned candle at both ends to try to get all the way to public beta this year, but at this point the build just isn’t ready yet.
I’ll describe in detail below what the one bug is that is really holding back public beta, and I’ll try to do a general FAQ about Vulkan and Metal tomorrow; based on the 150+ comments from the last post, I think it’s clear that we have a lot of basic info to get out there, some of which has only been shared with third party developers until very recently.
Please don’t bombard me with “can I please be in the private beta” (or even “you’re a giant pile of moose poop for not letting me into the private beta”). Here’s the thing about the private beta: our goal is to kill off the bugs so everyone can use the beta, and to kill them off as rapidly as possible.
At this point the dozen or so third party developers who are banging on the beta are generating bug reports faster than Sidney and I can fix them – if we add more people to the beta, our bug fix rate will slow down as we have to spend more time triaging the reports coming in. So as long as we’re fixing the worst bugs productively, more people in the private beta means everyone waits longer to get to public beta. I think the best thing here is for Sidney and I to just try to fix things ASAP.
(I think there’s also a win to getting this into the hands of third party developers – in some cases we’ve seen add-ons that accidentally use the wrong APIs for processing and are thus incompatible with Vulkan when they don’t need to be – developers can get a head start on updating this code.) If you are a third party developer, we can get you into the beta program – I don’t want to favor some third party developers over others.
Blurry Textures
A short summary of performance feedback from our internal beta might go like this: smoothness and FPS are good, VRAM management is not.
Most of the crashes while flying we have seen look like the sim runs out of VRAM and isn’t able to recover, and for users with smaller GPUs (e.g. 4 GB of VRAM) X-Plane gets into a tight VRAM situation and solves it by making everything on screen low res and blurry.
The VRAM management path, which is entirely new code written for the Vulkan/Metal back-ends, is…well, it’s entirely new, and it’s going to need a bunch of testing, debugging and iteration to get solid. On an 8 GB card, VRAM is so plentiful that X-Plane’s somewhat naive VRAM allocation scheme works fine. On a 4 GB card, we’re just a tiny bit short (a few hundred MB) but the result is an alarming loss of texture resolution.
This is something we can make better! It is under our control and is thus being worked on now. (By Sidney that is – I’m writing this blog post while he gets the real work done here.) But until we have better VRAM management, it’s too soon to go public. If we did, we would just be inundated with hundreds of “my textures are blurry” reports. It’s a bug too noisy to ship with.
Why Wasn’t This a Problem on OpenGL?
One might ask: why don’t you just do whatever OpenGL did to manage VRAM? The problem is: OpenGL’s solution is to stutter.
The OpenGL driver swaps textures between VRAM and system memory based on what you really need to draw now. If you are looking away from Seattle, the space needle’s texture can live in system memory, but you might need mountain textures for Rainier.
We try to do that too – the big difference is: OpenGL will stop rendering while it moves the textures around, and we will not. The result is that OpenGL always shows you a perfect image at the texture resolution you picked – no blurred images. But you might have stutters! You can see this if you’re on the margins of VRAM by flying and then changing views or circling the camera – if your FPS go “chunk chunk chunk VROOOM” you’re eating some stutters while textures move around, then you go fast again.
The OpenGL way is a solution that we never thought was acceptable – our goal is the best image quality without sacrificing smoothness. It’s going to take a little more time to iron out low VRAM situations, but once we get there I think it will be worth it.
Thanks for being so candid Ben. Good luck to both Sidney and yourself in your efforts to get this revolutionary version out in beta.
Thanks and Happy New Year to all at Laminar
*Sydney
*Sidney
Ben & Team,
Thanks for all the hard work. Get some sleep!
Ben, You all are doing just fine. There are always going to be the ones who scream and whine about betas and releases and complain about ATC and water and blah blah blah but those are usually the ones who’ll be the first to jump ship for a flashier product with no depth. X Plane has always been better where it counts and those of us who know about Laminar and truly enjoy flying a great sim developed by a great team do not mind waiting patiently for a better product and won’t hold you to unrealistic expectations or deadlines. This is a huge change for XP and we get that. I know I speak for the average consumer/addict when I tell you that we are thankful for all of you guys’ hard work, long nights and thankless hours spent putting out fires on the internet while creating the greatest consumer flight simulator i’ve ever played. Carry on and Happy New Year!
Well Said!
+1
I will ditto these comments! I think X-Plane is probably the best-value I have ever run in a flight simulator.
Nice update guys, know its appreciated by the community and have a Happy New Year 🙂
Ben, I fully agree with the previous posts. You can only burn the midnight oil so long so get some rest, have a beer and watch a few Monty Python clips. You (plural) missed your self proclaimed dead-line, which is a bummer but no biggie. It is the end result that counts and we all know that is going to be awesome.
Thanks for all the hard work, and Happy New Year to you and the rest of the team.
+1 Precisely what I was going to post.
You tried for New Year but now give yourselves a break.
You will probably find some time away actually helps once you get over th innitial himp of finding your mental bookmark in the code.
+1 especially the one with the Monty Python Clips and Beer 😉
But now something completely different. Take your time. The product is running great now. And it can only be better. Happy new year to all!
Great job as always. Better to have a smooth product rather than just flinging it out the door. We have all waited long enough so what’s the issue waiting that little longer to get polished version, than a half hashed version full of bugs that disappoints everyone.
I have 4 GB VRAM
so should I wait till full release?
I expect we’ll have 4 GB working with the public beta. But you can always turn off the Vulkan driver and go back to GL during the beta for more stability.
And…heck yeah, you can always sit out a beta, if you’re not a third party dev, you can just wait for final.
Moose poop.
I lol’d at that.
Great update, I’m overly happy to wait when I know it’s so you guys can make sure you’ve done the best job you can. Keep up the great work!
Moose poop: I hope there won’t be moose poops left on the runways. There’s deer already.
Is there any shareable info at this stage about distribution of CPU workload comparing OpenGL and Vulkan? would be very interesting.
and big thanks for all tremendous work being done.
It’s less CPU work-load on Vulkan. :-). I don’t have detailed numbers off-hand, Sidney might, but I do remember that:
– driver overhead is very similar for NV and AMD.
– driver overhead for both AMD and NV is lower than the NV Windows OpenGL driver, the previous fastest driver we had access to.
On Mac, a draw call on Metal takes about 1/10th the CPU of an OpenGL one from what we can tell.
Wow……
Reading it in a different way, it is like giving more CPU battery for third-party developers to build on top of x-plane, like weather ad-dons..etc… every body is winner eventually..
What’s a CPU battery?
if you notice the CPU utilization when using xplane under opengl, there is a single core that is fully utilized, that has the main thread,
by saying ‘More battery’ – i mean that the main thread should put less stress/burden on the subject core, attributing this to the new lighter weight vulkan driver overhead, thus leaving more room to utilize the main core thread for other tasks..
See these videos for a better idea..
https://www.youtube.com/watch?v=Nt4Q7eqtrNA
https://www.youtube.com/watch?v=SBhJSsBmWL8
Awesome work, time to chill and grab a beer. All the best.
Don’t worry, it’s better to go slowly and safely. The critics will always be there, and even more so doing things in a hurry.
Happy New Year to the whole team.
Thanks for your open style update! I guess the pain is in the details as often is the case. You focused rather on the use of graphicscard. Can you shine a bit of light on the use of the CPU with this beta, in particular the multicore utilisation?
Thanks for the update Ben.
Chill guys just chill, take some time out & all the very best to the team for 2020.
Hello, I read the news on the postponed publication of X-plane 11.50 beta 1. It is a great thing to release at least one working beta 1, without blurries and vram problems. It could also be a marketing matter, as fs2020 is expected to be released in March. Anyway it is not easy to change graphic libraries on a simulator based on another opengl graphic engine, you risk ruining a splendid software. Anyway watching YouTube videos, it’s not bad but it has a high contrast. Anyway also aerofly fs2, has passed with the same simulator to the vulkan bees. I have to say top top and top. Have a nice day and Happy New Year in Austin and all your staff.
MSFS will def not be releasing in March.
more likely March 21′ next year at that
Thanks for all the hard work. Xplane has come a long way since I started using Xplane 9, that is only because of you and people like you that put a lot of work into continually making it better.
First of all, I wish you a very good year and I always want to thank all your team for their work, but I think that not releasing a beta version is a mistake, who downloads knows that they may have a problem and is responsible for that and releasing this ” B “can collect more information from users and more small developers.but I can also understand your decision, as I said before, I wish you an excellent time for you and your family
If there’s one thing experience has shown us, it’s that a lot of users downloading betas do not believe themselves to be signing up for something that might make their installation unusable for recreational flights.
We could add a series of confirmations—”Are you sure you want the beta? Are you really, really sure? It might be buggy! Are you sure?”—but at the end of the day, some people are going to download it to get the latest & greatest features… and then be angry (like, “1 star review” angry) when it’s horribly broken.
Yes, it’s a sad reality! That’s why I also understand the decision not to launch the beta today
That’s why I use a large (2TB) SSHD and keep a good copy of the non-beta and two copies (a and b) of the beta. That way, I can leap frog through the betas and, if there is a good one followed by a not_so_good one, I am still flying. If all else fails, I still have my non-beta. If everyone would realize that betas are just that and prepare, there would be no problems. Thanks for your attention to detail, but I still expect problems and am grateful for your sharing the experience with us.
That’s a good idea (having two copies). I’d only wish it were easy to share global scenery between installations… As long as there’s no deduplicating filesystem.
Easier than creating a symlink?
I have a large 2Tb SSD that is dedicated only to X-Plane, and since my x-plane is currently 1.83Tb I have no space for two installs (a Beta and a non-Beta) 😀
Well, maybe than public betas shall not be “horribly broken”. I am testing each beta myself and I am really often stuck by some trivial bug, which should never pass to public beta. And surprisingly some of these (same!), pass there again and again. How many times there was problem with external visuals synchronization? ;-p Also very often by fixing one bug, you broke something which was already working. So please do not rush things and instead of half-bake beta releases invest more into proper automated testing. Especially now, when a lot of code was changed. Thank you.
Wow – that’s the most bratty thing I’ve read in 2020, and maybe even in 2019.
Thank you for your comments and inspiration!
All my respect for your creativity.
Keep up the great work guys!
Happy New year 2020!!!
lknfly
I know people want the Beta’s asap, especially Vulkan but surely it’s good practice for 3rd party Devs access to Beta’s before the General public.
In regards to nvidia users, will threaded optimization be of any benefit with Vulkan?
I really really really really hope the answer is no!!!!
The OpenGL spec is quite vague about performance – you ask the driver to draw and the spec is clear about:
1. What will be drawn.
2. That it will be drawn _someday_ in the future and won’t take forever.
3. That the driver isn’t allowed to blue screen your machine ever, and it’s not allowed to crash your app in some cases.
It says nothing about what is fast and slow – everything is “do yer best”, and it’s up to developers like me to try to read the tea leafs to guess what make things better.
So in this context, NVidia made an option where they tried to split the CPU work from the driver out into an extra thread. It’s a gamble.
– If the app is massively single thread bound on the renderer, like X-Plane this can be a big win! Parallelism. Go green team!
– If the app has scheduled work on ALL of the cores (like X-Plane) for FFT water, AI planes and scenery loading, and then NV goes and tries to use those cores, we’ll overload the CPU and scheduling of everything gets really bad and you get 4 fps.
Vulkan aims for predictable reliable performance: everything CAN be multi-core (no locks inside the driver) but all the multi-core is up to the app. This way the app can use the entire CPU but not overload it.
So there’s no place in Vulkan to have a ‘we thread it for you’ option — and if they did, they’d be violating the spirit of Vulkan, which is: driver doe simple fast things and apps are in charge.
I wish this Vulkan adoption to finish fast.
Why? …
Well because I would like to see other improvements for the Simulation usage>
My main concern is multi crew via internet normal bandwidth (not 1 gbps
symmetric connection :D)
Built-in communication (for interphone while multicrewing) and also radio
communication based on freq, distance and power… human atc maybe.
Also a Planemaker renew.
I know Vulkan will take tons of time, but this is what I’d like after this new API base (foundations) is totally firm and usable.
Thank you Laminar for this great simulation software!!
Vulkan is into 3rd year of development. Just to switch to alternative graphics API. The other devs have been reassigned to GloMo cell phone version. Austin is making movies and doing side projects, and YouTube reviews. Meanwhile there’s still a long list of issues and defects in XP. Environment problems and weak visuals. Unoptimized code (ie reflections) since 2016. Still not fixed. And it’s Still single core! They blew it. It’s going to be all over.
Who knows if you’re right or not.
I was just only trying to see beyond the dust cloud Vulkan is doing all around the scene. It surely needed the new graphics API. But also needs other features not so tided to essentially performance.
I´m expressing what would be nice to have after all this has settle down (name it in 1 year or whenever).
So, basically I like to see more the horizon than the actual close picture.
Good luck fixing the bugs. Also, dont over do it ! Wishing the team happy holidays.
Excellent feedback, Ben, as usual. As I said before, moving from OpenGL to Vulkan is a bit like doing open heart surgery while the patient is jogging. I’ve swapped out major sub-systems on software before so I get it…. 🙂
I have plenty of final flying to do in the OpenGL world so take the time you need.
that’s very good news, we will wait.
the best news ever is to hear we are finally getting rid of that absolute immersion ruining “stuttering” annoyance caused when changing views or circling the camera as you described it !
weeww if we will get rid of that stuttery crap that’ll be an amazing progress!
happy new year
I have a Intel i7 quad core processor and Intel iris graphics would my FPS increase with vulkan as I have a lot of cpu ?
X-Plane is essentially a single core/thread application, so multiple cores aren’t necessarily of benefit. We don’t want to spin this topic up again, here, as it covered many other places here on the forum.
Wait – this is definitely not true.
X-Plane’s main scenery rendering path _is_ single core, and this can often be a huge bottleneck. Similarly, plugin code is single core unless plugin authors make it multicore, which is a lot of work since the SDK doesn’t help.
But all of the scenery loading and preparation process is pure multi-core and it is _always_ running while you fly. Same with AI planes, some of the per-frame work, and various misc tasks. So users with dual core machines find they don’t have enough cores to fly smoothly at high framerate.
Wait – that is not entirely whole true, right?
X-plane current level of parallelization is able to gain up to say 4-6 cores maximum. And as we already know neither IPC (instructions per clock) neither CPU frequency (clock) will increase as fast as it did in the past. So current trend (an already last 2 years – thank you AMD) is to increase number of CPU cores. So today 8 CPU cores is average and 16-32 is more likely desktop high end and lets see Ryzen3. 🙂
The only issue with that is, that in last two years, while available number of CPU cores increased each year, reaction from Laminar was zero. Means no more thread optimizations implemented to be able to load more than these 4-6 cores efficiently.
Yes, Vulkan is very good first step in this direction, but be honest, there is train to catch and Laminar is not even at stable Vulkan yet. And so we can very likely expect this kind of optimization delivered only in XPL12, definitely after MSFS2020 release.
It depends: If the main task is moving data, multiple threads won’t help much as the RAM is the bottleneck. When the task is math-heavy, there’s an advantage.
Also be aware that current systems are all NUMA systems where not all threads are tested equal, and there’s a thermal limit for all the cores.
As an amazing side note: I can hear thread usage as noide from my CPU fan, just as for the GPU usage. I have software that keeps all threads at almost 100%, but that’s not X-Plane; X-Plane keeps my GPU at 100%…
Thanks for the clarification to my generic “essentially” phrasing. 🙂
just as a side note small side notification to this part:
->Similarly, plugin code is single core unless plugin authors make it multicore, which is a lot of work since the SDK doesn’t help.
Some work has already begun for the YA747 project to add multithreading to xlua scripts. No real time frame for when or even if this will be successful – a lot of work is putting it mildly. But if and when that makes even a first release this problem should be massively alleviated.
I’d be curious to see what the threaded XLua code looks like. A Lua VM is a good candidate to run in a thread in that it has total isolation from the sim _other_ than the holes you poke in it by function calls. So you can build a good sand-box by default.
I just wanted to add a thank you to this thread, your work is very much appreciated, so take it at your own pace and keep up the energy.
It’s clear to see it takes great effort and much attention to detail to make your ideas real, but you guys still manage to stay positive through it all, so stick with it and wonderful things will happen.
Ben, Thank you for writing this. It is much, much easier to be waiting in the wings (ba dum tssshh) when we have a better idea of what is going on behind those closed doors. Happy new year, and thank you for all your hard work.
My take away from this: You guys worked over the Christmas holiday 🙁
Anyway, thanks for the update, my 11GB VRAM GPU is waiting patiently.
That’s not entirely true. I hit the slopes on boxing day and then promptly caught the flu as karmic payback for leaving the office 😀
Yep, I understand, I’ve been on leave since middle of December, and everyone in the family including me got sick the next day… Oh well back to work tomorrow 🙂
Microsoft has released DirectX 12, the latest generation of its Graphics API, and Apple has released its Metal 5 API. Both plan to use the same low-level hardware access and mobile portability as Mantle or Vulkan. So why insist on kulkan / Metal?
Wait – I think there’s some confusion here.
Apple has Metal (updated incrementally in a major way twice now) for OS X and iOS.
Microsoft has DX12 for Windows and I guess XBox.
Khronos has Vulkan for Windows, Linux and Android.
AMD has Mantle for Windows – you can think of it as a pre-Vulkan R&D project – I think AMD’d tell you “use Vulkan” at this point, but a lot of the innovation in low level drivers comes from Mantle.
We picked Metal and Vulkan, because those two back-ends give us _all_ of our platforms: Linux as well as Windows with no new back-end on desktop, and we get Android for mobile too.
DX12 would not give us any platform we don’t get with Vulkan, nor would it get us any features we don’t get from Vulkan.
Now that X-Plane has been heavily refactored to use multiple back-end drivers, we could do a back-end driver for DX12, and it wouldn’t take that long. But there’s no win there.
Linux <3 I am so glad that you do support Linux. It is the only way for me to fly.
Will also like to compliment the team for your hard work. I see and appreciate the results of your hard work.
As a side note: Linux users could try the betas with little risk using a union filesystem: Use the stable version as base and mount a new layer on top before upgrading to beta. If things broke badly, just remove the top layer and you are back at stable…
However this is an advanced topic for geeks…
I guess that’s a also an advantage if for any reasons Microsoft would cut Vulkan access to windows, you could put out a DX12 back-end in a timely manner…
Still, it would be an additional thing to maintain. But that will probably not happen anyway.
“We picked Metal and Vulkan, because those two back-ends give us _all_ of our platforms: Linux as well as Windows with no new back-end on desktop, and we get Android for mobile too.”
If you had abandoned the tiny fraction of Mac and Linux users, and focused on your biggest market, Win users, would you have still made the same decision to pick V/M?
So first, Mac is about 1/3 of our market. So while I can try to speculatively answer the question, I want to be clear about what the numbers actually are. Sometimes people suggest in the comment section that if we would just drop the Mac, things would become magically awesome for the sim. We would save some mac specific aggravation, but, having ported to Metal there really isn’t a “but what about the Mac” hosing us, and if I go to Austin and go “hey, Austin, I have a great idea for a feature that will CUT sales by 1/3” he’s gonna have some uncharitable questions.
Our current strategy is “back-end agnostic” – that is, the sim can run against multiple drivers. This is a proven design that you see in lots and lots of other games and engines, and we’d almost certainly have the abstraction regardless of what _specific_ back-end we’d pick, e.g. we wouldn’t just jump from being “locked into OpenGL” to being “locked into Vulkan” or “locked into DX12”.
Now the second thing pushing us toward Vulkan is it gets us Vulkan on Android instead of GLES 3. So when we talk about covering all platforms, remember there are five of them, not three, because mobile and desktop share a ton of low level code. So we’d have to pick between just Vulkan for Android + Windows vs DX12 on Windows on and Vulkan on Android – I have never seen something that is unique to DX12 that’s not in Vulkan that would make it worth doing _more_ back-ends.
We’d probably still do Metal for iOS, but the timeframe wouldn’t be simultaneous to desktop – it’d happen whenever we moved the graphics refactors to mobile (which has mostly not happened yet).
there is no confusion, but they have the disadvantage of not being cross-platform.
hAppy newe gyear andf thankls for efforts¡¡¡, goods nigts, it hasd beenm a loooong noight of xelevratioms.
Its 2020! Hope The Beta 11.50 Comes out real soon!
This weekend relased X-plane 11.50 beta 1 ?
Can you comment on oculus VR HW recommendations using Vulcan? Not the minimum, not the spare no expense, but the value sweet spot? Should I expect 45fps?
Considering upgrading PC. Currently…I5-7600k + 16GB RAM + vega64 8GB VRAM, Win10. Machine dedicated to Xplane.
For 11.50. Will more than 4 cores help? Or more Mem ? Or better GPU?
Currently getting ~30fps. Excited to try the 11.50 when released and hopefully avoid all the tuning hacks to get 45fps and no stutters.
Well explained, Ben! Much appreciated!
+1
Hi Ben and all,
You are doing great job with the simulator! It is great to hear that you are so far with the Vulkan version development. Cannot wait to try it out!
Happy New Year! 🙂
-Tuomas
I’m running an i9 9900K z390 hackintosh with a Radeon VII. Getting low 30’s fps with high scenery settings running 1080p on a 4K monitor. Looking forward to seeing how Metal implementation will improve things! Will there be any benefits to a multi-gpu rig? Maybe not initially, but eventually? I have an egpu I can use with this rig via Thunderbolt 3 or I might add a second gpu internally.
Fantastic work! The dedication is so impressive.
Happy New Year!
Thanks Ben and Sydney. As excited as we are, we understand the challenges of new technology and software development. Thanks for working so hard to make it amazing and will stand by with baited breath. Happy New Year!!
Please also consider the VRAM consumption of plugins. The plugin DLL FSTramp uses Direct3D and requires 0.5 GB VRAM on a 4k display. These are not static bitmaps but several layers of the final image which are drawn into the VRAM simultaneously.
Sidney’s VRAM management system _should_ theoretically take this into account – it talks to the driver about how much VRAM is free and tries to cope with “dark matter” – VRAM used up that we can’t explain, e.g. from plugins.
your hard work and candidness is appreciated especially to technophobes like me who used to create stuff in fortran and cobol just after pontius was a pilot,
Great work. really looking forward to testing Vulkan and a Radeon VII.
@Ben: Any use or benefit that you see with 16GB VRAM cards? Can Xplane really use them for speed advantage?
I was about to post a very similar question regarding the VII. Is it just eliminating the risk of blurred textures?
Please don’t be shackled by a date. It’s better to take your time and put out a product that you are proud of instead of regret.
Happy New Year.
I run X-Plane 11.40 with the Zibo 737 mod on my laptop, which only has 2 GB VRAM. But on medium graphics it works ok. When I see you mention that you’re trying to improve the graphics on 4 GB VRAM, that worries me. Will I be able to run 11.50?
And I join others in thanking you for your hard work. Happy New Year.
You will – we’re not making 4 GB of VRAM minimum. We gotta make 4 work before we look at 2.
What about a 2013 Mac Pro with dual 3GB Firepro D500 GPUs? Does X-Plane’s implementation with metal take advantage of the second card?
(Does Austin still run his “trashcan’?)
The metal version, like the GL version, does not take advantage of the second card. As I have said before, I have _no_ intention to try to optimize the case where two cards drive one display, ever. In the case of the D500 Mac Pro, it’s just a very, very silly piece of hardware for X-Plane, because the thermal budget of the two small cards is mis-used for X-Plane. Austin does still have his trash can, and it’s not a good X-Plane machine for its price. It is, however, a very portable dev machine, which is quite useful for Austin.
But you’re open to the idea of a card running another display? Ie 3 displays therefore 3 video cards?
In the long term, yes, it’s something I’d like to evaluate (but not in the trash can, pick something more suitable ;-).
I’ll take it as with 6GB of RAM everything as fine? One way or another, good job and happy New Year!
Hi Ben, and happy New Year to you!!!
Well done on all your hard work; you and the team really do deserve some rest!
Regarding performance…is it still the case that Nvidia is the preferred GPU, or do the improvements with Vulcan now mean that both Nvidia and AMD are evenly matched?
Many thanks!
Dom
We think it’s gonna be evenly matched and you’ll be able to just pick a GPU based on the GPU’s actual perf (as it should be) but probably more testing later in the beta is needed. Red and green team had quite similar driver overhead in our pre-beta testing.
On VRAM vs. RAM: I see similarities to OS paging: If the OS is busy with moving pages in and out, performance will suffer; if the OS (a thread) has to wait for a page, the performance will suffer, too. So the OS has an additional cache between both.
My idea: Build a queue of objects out of sight plus a priority based on lack of VRAM: A background thread at that priority would then move those objects (maybe old and large objects preferred) to RAM, freeing VRAM (and the queue).
So there would always be enough free VRAM. However the “page in” (object from RAM needed in VRAM) would still be synchronous, i.e.: Someone has to wait for it.
Of course if you can anticipate the objects being needed, you could construct a similar page-in queue, or at least cancel the page-out…
Hi Ben,
I asked about use of the layer system in your previous post but didn’t get a chance to reply before comments were closed.
I was referring to using a layer to do some sort of drawing; perhaps as simple as text-only.
Regards,
Karl
Ah. Technically a third party developer with a lot of time on their hands and a willingness to write a lot of code that would almost certainly be broken the very next time I looked at Vulkan could use the layer system to _wrap_ our interaction with the Vulkan driver and interject almost anything they want into the sim. (I supposed you could also just replace the loader and go that way.)
This would be similar to FlyInside wrapping the entire OpenGL API and rewriting our shaders and messing with our draw call stream to make VR work on non-VR-enabled X-Planes like v10.
There are two big down-sides here:
1. It’s a _ton_ of work. The view of the sim you get is like watching a city speed by through a pin-hole…a giant pile of random API calls with no rhyme or reason. It’s a lot of work for the programmer to sort them out.
2. It’s got _zero_ future compatibility. “How we talk to the driver” is not an SDK or API and changes in both intentional ways when we do any development, and even in unintentional ways just by authors changing content. So you’d be signing up to have your work broken over and over.
I thought that was actually fine for FlyInside and v10 – since v10 was end of lifed AND we never intended to do VR (those two things sort of go together) they could have things in once and call it a day. But for v11, mid-development cycle, it was just asking to have their add-on broken repeatedly.
cheers
Ben
Thanks for the detailed reply.
Could you expand on 2) “How we talk to the driver” is not an SDK or API… I’m far from an expert on Vulkan but understand that it has a well-defined API (Khronos) and SDK (LunarG).
Thanks very much.
The _driver’s API_ (e.g. Vulkan, OpenGL, Metal) is absolutely a well-defined API. It has clear rules – what happens when you call X, what is legal and what is illegal, bla bla bla.
_Our usage_ of the driver is not a well-defined API at all. For example, the _order_ that X-Plane renders its various FBOs has changed during the v11 version run as we went from 11.20 to 11.30 to 11.50. Vulkan says _nothing_ about what order we render our passes, or even what is IN our passes.
So a Vulkan layer that is based on _Vulkan’s_ API can do sane things. This is how the validation layers work. Because it is well-defined that when we say “start render pass” we have to pass a render-pass object, if we call “start render pass” without a valid RP object, the validation layer can go “hey, you are doing something stupid”. That’s sort of the point of the validation layer – to do slower error checking to help app devs find bugs.
But what about a Vulkan layer whose goal is to _insert_ drawing onto X-Plane’s screen? Well, if you knew _which_ call to end a render pass was us ending the render pass for the FBO for the main window, you could go “a ha! I’ll just add a send a few more drawing commands to the driver, THEN end pass through the “end render pass” – and viola! You’ve injected extra Vulkan driver commands into our command stream.
But when is the right time to do that if you want to achieve an effect (E.g. 3-d drawing or 2-d drawing on top of 3-d, or customizing the sky dome, or any other trick you could do if you could modify our frame arbitrarily)?
The answer is: who knows! It’s NOT SPECIFIED. And it might change in the next version of the sim. The USAGE of Vulkan by X-Plane is not standardized – only the Vulkan API itself is.
Thanks again, Ben, for taking the time to provide such a detailed reply.
Looking forward to great things in the XP world in 2020.
Kind regards,
Karl
“ and I’ll try to do a general FAQ about Vulkan and Metal tomorrow;”
This is not a complaint at all, but if you’ve seen a spike is server traffic, it’s me hitting reload to see if you’ve posted that.
Sorry! Know that if you do a FAQ, I’m interested 🙂
Sorry I haven’t gotten to this yet. I started a FAQ and I don’t think I’m winning with it. It was hard to get both questions and answers that were both simple. The simple questions (will X work with Vulkan) have complex answers (it depends) and the simple answers (your add-on will definitely just work if it doesn’t have a plugin) answer complex questions (will my scenery packs that are not plugin enhanced need updating).
Ben Supnik said: In 11.41 we added the mic entitlement to our list, hopefully fixing the issue. Only X-Plane could fix this – plugin DLLs don’t get security entitlements, as it’s on the process level.
Can we expect camera entitlement in 11.50? Please.
The CAMERA entitlement?? What do you need it for?
I need it for my long standing TrackerXP plugin: https://forums.x-plane.org/index.php?/files/file/21278-trackerxp-340-demo/
Thanks..
Hi Ben,
Im currently into looking into upgrading my CPU (GPU 2070 Super) and cant decide between i7-9700K and the AMD 3700X. What do you think will run better in Vulkan? The Multicore-Multithread machine Ryzen or the Single Core Beast 9700K
Cheers
Kevin
Multi-core use is only slightly more important in 11.50. Since we do things that used to stutter on other cores now, if you run out of cores, that doesn’t help, but we won’t use 8 cores to render a frame.
Okay thanks. So basically the higher core speed of a CPU with less threads will benefit more, thanks.
9700K will run better +15% more FPS
Does 11.50 support nvidias new vrss technology?
No. It does look like useful tech for VR and also SSRs.
Dont you think it would make sense to adjust the graphics settings automatically and also adjust them during the flight? Maybe the optimal setting would be different when you are on the ground than in high alititude?
A lot of the graphics settings require major rebuilding of data in the rendering engine to take effect, so they’re not good candidates for dynamic changes.
Dear Dev-Team,
just ouf of curiosity: how is the bug fixing process going on? Did you manage to solve the blurry texture problem? Perhaps you like to share some insights. My kids and I are thrilled to test the upcoming beta patch :-).
Have a good time.
Slow but steady. We’ve gotten great bug reports from third party devs on the private beta, but the blurry texture problem isn’t a one-day fix kind of thing.
What if on vram starved systems you did a conversion to 16 but textures (5, 6, & 5 bits per channel) at load?
Or would lack of alpha channel blow things up?
How does VRAM allocation work with plugins that load objects including particles? Are plugin load objects treated differently to scenery etc?
Looking forward to testing the beta with thousands of objects with particles compared to OpenGL.
If a plugin induces the loading of an X-Plane art asset (OBJ, particles, etc.) VRAM is managed transparently for the plugin using the same mechanism as if the scenery were doing loads:
– Loading the new textures may increase VRAM pressure.
– We may page some stuff out to deal with it.
– If OTHER stuff pages out (e.g. you fly away from Las Vegas and we can page out all of Cristianos’ nice buildings 🙂 then if VRAM pressure releases enough, the plugin loaded art assets might INCREASE their res to use the free space, just like the rest of the scenery system.
If a plugin just uses VRAM directly (e.g. it calls glTexImage2D and allocates a giant 64 MB texture) then we notice VRAM pressure when the Vulkan driver tells us “hey there’s less VRAM now” (cuz the driver sees all) and we may page out some stuff.