X-Plane 11.50b4 is now available if you update via the Laminar Research installer. (Steam users: it’s on the servers and we’ll hit go in a few hours if we don’t hear reports of massive crashing and pain again.)
This update was focused on crash fixes and better triaging. We’ve been seeing a huge uptick in volume of bug reports and auto reported crashes since the initial 11.50 public beta release. We are trying to cut through the noise and provide better information in logs and in the remaining crash reports to fix issues faster, and let our support team (primarily me) get the inbox under control.
The best way to help us handle crashes on Windows and Linux is still to submit the auto report form. You can include your email if you want us to be able to find your specific crash, but we do not need the message field–the log and back trace will have pretty much all the info we need. If you send an auto report, please do not also send a bug report form email.
Mac users do not have the ability to auto report, so they should fill out the bug report form, and include the Apple crash report as well as the log.txt. This can be found under your username /Libraries/Logs/DiagnosticReports. The name will include the date & time of the crash and will end in .crash. You may need to show hidden folders to access it.
There’s No Way For Me To Report This Via Bug Reporter But My XP11 Like To Blue Screen My Windows Don’t Know If That’s My Windows Or Xp11 Never Did It Before
Yes there is. The bug reporter is a _web site_. You can’t _auto-crash-report_ that cuz your machine blew up, but you can file a real bug.
ok thanks i mean crashes are a mere flesh wound
PLEASE PLEASE PLEASE Ben give us more control of the sim..
For me and many others the problem is FPS and memory..
I Don’t want cars and I don’t want to see buildings far far away, just uses up system resources I do not have, so why not give me the choice to remove them? or reduce the visual range or add night lighting?. why do we need to HACK the game in order to get Basic display settings?.. for me this has been the single and biggest Issue with Xplane and opens up so many doors to problems..
please please give us more control of the display content so we can tweek the sim to our own systems and not a Basic low med and high…
I agree, the default viewing distance for objects in X-Plane is totally overkill for my preference. You can reduce it by 25% and gain a huge FPS boost without any noticeable quality difference.
I understand that XP10 had too many rendering options which confused users and led to sub-optimal rendering settings. However I think most of us are mature enough to be able to handle a view distance slider at least.
100% agree. A lot of these controls are locked behind complex settings text file or tools that no longer work in the beta. Used to be able to tweak forest density and road density and shadows quality on the fly but now I can’t do that very well
And if you have bsod, there should be a minidump.dmp somewhere in the windows directory, you may attach to the bugreport.
Bluescreens are an indication of some deeper system issue (drivers or hardware).
For a more convenient access to the information they generate, you can have a look at this tool https://www.nirsoft.net/utils/blue_screen_view.html which shows a list of stored dumps and where the crashes happened, and who made the offending system component. It also lets you copy information to attach to a report.
I’ve had two as well which didn’t seem to be an issue with b1, both happened several hours into flight. Unfortunately minidumps were disabled, I’ll definitely try to catch the next one.
Disregard, it turned out that my memory was unstable. It passed however every stress test and ran fine in these conditions for the last 6 months. It seems that LR unintentionally devised an effective edge case memory stress test. That’s no surprise, this game is pretty memory intensive.
May it serve as a reminder to all of us running tightened memory timings, you might have unexpected issues with this one.
Yes … next round 😉
Thanks a lot for your work and patience!
Returning to 11.40, 11.50 only bugs for me failed to allocate sufficient GPU memory.
File it. That is the purpose of the beta version 🙂
I have exactly the same, I already file it twice. I had no problems with 11.41. It seems that Vulkan is not able to use the shared GPU memory I have.
Compliment Ben and all staff for the rapid work progress, we hope the same for the work of third-party developers
Hey Ben after the beta update 11.50 I’ve noticed that when you on VR the cursor arrow sinks in the cockpit when you try to click or flip switches is that still a problem after b3,b4?
I don’t think that it’s still a problem according the list of bug fixes regarding b4 specifically, which includes “XPD-10701 Mouse cursor in VR mispositioned.”
Do you have a link that can get me started on this xplane version ?
What do you want?
Honestly, if you don’t know how to install a beta, you should not be installing a beta
You have to update via Installer client in your X-Plane 11 main folder.. follow the instructions and check the box „beta updates“
Use the Xplane 11 installer.
Once you start it there will be a box on one of the screens to tick that say’s something like ‘install beta version’.
Tick that box and continue the install/update and step into Pandora’s box…
😉
to have the beta you need to select the option in the X-Plane installer “Check for new betas as well as updates”
Thanks for all of your hard work! Working through the crashes, mine seems to do okay then load up on memory use after time but restarting my machine seems to fix that. I AM LOVING 1150 SO FAR! It’s been the single greatest update since I’ve been an XP user. Keep it up
Hey Ben and team, are you getting any closer to finding the bug that crashes XPlane when you leave VR and go back into VR in the same flight?
What does your log say when it happens?
Is that still an issue with b4? We fixed a couple of nasty bugs with VR and I was really hoping this would resolve itself. Unfortunately I’ve been unable to reproduce this with any of my devices here, but device losses are a very high priority for us.
It’s still happening in beta4 Sidney. If there is any specific additional information that can be provided then let us know and I’ll submit it.
Yep, I get it too with a Windows MR HP Reverb.
I got one of these too in b4. I’ve submitted a bug report. It happened right after I woke up my WMR controller. It had automatically gone to sleep due to idle time. It might be a coincidence though. Hopefully the error log I submitted sheds some light to the error.
I updated beta from xp11.41 and everything was ok, now that i reinstalled xplane from the begin ( cd version) and i jumped directly to 11.5b4 i have continuous loss of device switching to vr with hp reverb
Hi Sidney,
No the problem hasn’t been fixed, I’ve logged a few bug reports under the same email i use for responding here. It’s stopping me doing any further testing as I solely use XP for VR.
Please fix the flickering clouds. A smoother, non-flickering cloud shadow movement transition … and those jagged, aliasing shadows! It’s awful !!
It’s not only clouds and shadows. For me also ground and tuigen flickers.
should be: For me also ground and autogen flicker.
I have fixed it. Activate “Draw shadowa on scnery”. Before I had to deactivate it because it was poorly managed, now it is quite better and almost without aliasing …+ 3DFPS (plugin) a little better
Sure, the cloud shadows are still flickering, the stage is blurred when you quickly move the camera and, if I’m honest, the brutal drop in “FPS” becomes very annoying. The good thing that reading “FSP” does it very well. The bad thing is that the granulation of the stage surfaces predominates. Please keep asking for the transition and movement of cloud shadows. Thanks for your effort because I have it is OpenGL for not installing Windows 10 since “SearchUI” prevents me from having a decent OS that, when I allow it to update, installs obsolete graphic drivers.
It should work properly without shadows. Also shadows reduce the fps a bit, therefore I don’t want to activate them.
use DataRefEditor or FlyWithLua and do this:
set( “sim/private/controls/clouds/limit_far”, 0.2 )
voilá, cloud flickering almost gone
Set this value too high and clouds near you will start flickering, set this too low and clouds far away will start having weird shadows.
Gracias Ramón pero, me puedes indicar en que fichero lua y en qué línea tengo que colocarlo. Si pones la dirección de dicho fichero sería completo. Un saludo .
Install FlyWithLua, then add a file in “X-Plane 11/Resources/plugins/FlyWithLua/Scripts” and add the set( … ) line from above to it. Then reload the FlyWithLua scripts from the X-Plane plugin menu.
Now that Metal is here, is there any hope of getting VR support on Mac?
At some point in the future, yes! We don’t have time in 11.50.
Great, can’t wait, no doubt that VR is the future of simming….
Hope that an eGPU can be avoided, but if it in 2022 can make my by then ancient 2017 iMac do VR via thunderbolt, then just perfect….
(< Just to say that please have eGPU in the back of your minds VR-wise….;- )
I am getting fairly regular crashes on a Mac Pro with macOS 10.15.4, and the latest beta does not appear to fix it. The crash is weird because it causes the display to go dark and then drops me at the login screen, but there’s no crash report. Anything useful I can look for to send you?
Thanks guys. Don’t give up.
I ran the installer but am unable to see 11.50. I only see 11.40 updates. Where can I get or see 11.50 ??
11.50 is a beta, you need to place a check mark in the beta box in the installer menu.
I am still getting the micro-stutters in VR. I have filed a couple of bugs related to this, should I keep filing them? I noticed there were some bugs fixed related to VR, but not sure if there was any under-the-hood work done to help VR performance especially around the smoothness. This happens with my Oculus Rift. I try not to use plug-ins during the beta, but it seems if I use a tool that ‘locks in’ the frame rate, the stuttering goes away a bit, but then I’m locked to a specific framerate. When I disable these tools completely and test with the beta versions, I get the micro-stutters again. For example: take the digital numbers on the 737 MCP – if I look directly at them and don’t move my head, they look clear and crisp. But if I start to turn my head, they stutter and get blurred a bit until my head stops moving. Almost like if you had too much to drink and move your head too fast… the world stutters a bit and gets blurry. (not that this has ever happened to me I saw it in a movie….)
Anyway, just wondering if this beta addressed any underlying VR smoothness issues. If so, I am not seeing them. And if not, are there plans to address additional smoothnes/stuttering/blurriness/FPS in future beta releases that we can test?
Thanks again for great progress!
If I where a LR employee, I would probably refer you to this excellent, and recent, blog post, which answers all your questions:
https:/2020/04/some-quick-notes-on-the-first-vulkan-metal-beta/
An, thanks I read that post when it came out and commented on it actually. I read the phases of development and priority for releasing beta builds. My question is around the micro-stuttering and if it was on the radar to be fixed. I guess I should have not used the term ‘blurry’ to describe my issue. It is more like… double vision. Like an exact copy of an image 1mm or so away from the first. Like looking at the MCP and the digital numbers for speed/altitude. When you move your head, it’s like the numbers get double-visioned and shake/micro-stutter. Not really blurry. More like stutter-y.
So I guess my questions is – are there plans in the 11.50 development/beta/release roadmap to address this kind of micro-stutter?
Again, I have filed defects using the bug reporter, so I don’t expect this to be an official defect report. Just a finding I wanted to share in the developer blog comments to see if others testing the beta have experienced anything like it. And maybe to see if one of the developers could comment on plans to address it.
Thanks, all!
I am seeing the very same thing trying to use VR on Ubuntu 18.04 LTS using my Valve Index on a i7 9700K and a RTX 2080Ti. This is a dual boot machine and do not see the same thing when I am using Windows so find your comments very interesting.
I had heard the term micro-stutters but this was the first time it was explained so it was clear to me. The term I have been using is double vision as what I am seeing on Linux the real image is there but there is a second image to the left or right depending on which direction you turned your head.
Thanks for the post Bill
What you’re describing is caused by insufficient frame rate. If you want a smooth VR experience you need to lower your settings to maintain half your headsets refresh rate at all times. That’s the only way Oculus asynchronous spacewarp can work as intended.
There is a 3rd party script to make reprojection work at lower frame rates on the rift but the result will not be as good as old frames are reprojected multiple times.
Respectfully, I disagree with this. I could probably lower my settings to all the way left on the GPU and CPU sliders, but wouldn’t that defeat the purpose of some of the benefits of moving to the Vulkan architecture? I have a i7700 1080ti with 11GB vram. I should get descent results with that system and reasonable settings. Sliders are set to objects on high, HDR, 2x AA and textures max. My GPU isn’t the issue here since the textures never full occupy the VRAM. CPU isn’t that taxed either. I am getting around 60 fps sitting on the ramp in non-VR mode. That should give me a smooth 30 fps (or at least 22 FPS) in VR. One of the enhancements that was to come out of the move to Vulkan was better management of textures and help eliminating stutters on a reasonable system with reasonable settings – which I believe I have.
Note that I am not complaining here about anything – just wondering if this type of things is planned to be addressed. For you to say, “Lower your settings to get a better experience…” well, I can probably do that in 11.41 if I lower things down to the point where my fairly powerful system renders a sim that looks a mess.
What you are describing is the effect of sitting somewhere in between 45 and 90 fps. You get a fluctuating framerate which shows as microstutters, and bluriness which is a secondary effect of asynchronous spacewarp kicking in to fill up that gap to 90 fps. You can confirm this with any software that can display your framerate (like MSI Afterburner, AviTab can display it as well).
To avoid that, your options are to either cap your framerate to 45 fps with or without ASW (both options are available through OculusDebugTool), or to lower your graphics settings until you hit a constant 90 fps.
Yes, I have seen the frame rates on AviTab and this does happen when the frame rate is anything other than 30 or 45 (even 22 seems to be ok). But is that really acceptable behavior for the product to exhibit? I don’t think it is and I am not the only one with this issue.
t would be nice to hear from someone on the product side on any plans to fix this or not. I really don’t think it is reasonable to ask someone to lower settings to the point where I am getting 90 FPS non-VR. That would mean moving world objects to almost off on my i7700 1080ti system. Is that reasonable for a user to have to go through to get VR to work with no stutters? I have read the roadmap for the betas and I know the priority right now is getting things stable. It would just be nice to hear from one of the product developers on whether or not any work is planned to get VR more smooth native in the product.
I am aware of the tools and utilities available to cap frame rates – there is the oculus debug tool, the oculus tray tool, the OVR settings plugin in… probably other ones out there too. But from a product development perspective, is it expected the end user resort to application-modifying plugins to get VR working in a smooth manner with reasonable settings on a fairly high-end system?
I have filed several defect reports on this. Again, it would just be nice to hear from someone that these types of issues are either being addressed in future beta phases or not.
I to have microstutters in VR, wasn’t so bad in beta 1 but now vulkan or open GL the stutters are the same.. Good FPS steady 60 but on occasion I’ll pan to some scenrey that overloads it.. I’m also 1080ti 12Gb… I honestly wish the devs would add advanced options so I can remove boats and view distance etc.. Using a 3d party software is more resource and causes crashes for me.. I would like to see independent autogen sliders, texture resolutions, include boats, birds, cars etc… I hate the fact we hafto Hack the game to get basic settings that I suspect would fix Alot of problems for a lot of people….
DLSS 2.0 planned?
No, as it is proprietary to Nvidia. Ben wrote about this in the past.
i hope XPlane Vulkan works with reshade
For me beta3 has been quite stable
as long as
I do not touch the
“change current time”-slider in flight!
Probably you have this already on your radar…
Please file a bug. It’s neeeeeever safe to assume someone else has reported it!
When do you think the final version will be released i’m very eager to see my FPS increase
But, at a certain altitude, I observe lots of black dots on the screen. it’s normal ? Is it a big ?
Thanks for your amazing work !!
I just want to thank LR team for pushing XP11 to a point where I can run my sim stutter free in 50-60fps range, all maxed out @ 2560 × 1440 (scenery shadows/reflections off) in a LA region.
Im using i3 8350k@4.0ghz/1060 6gb, it is so smoooooooooth now :)))))
KEEP UP A GREAT WORK!
For me XP11 is now the smoothest running sim of all.
HUUUUUGE +1 from me.
I have spent days fidling and messing around with settings and reverting back and forth between 11.41, 11.50 vulkan / non vulkan because no matter what I did in settings I had a way better fluidity in 11.41 compared to 11.50 – did’nt matter if vulkan was enabled or not ! (all other parameters was the same and I evaluated both on vanilla installations as well as my normal X-Plane installation with orthos and X-europe installed)
It was driving me nuts as the framerate counter in the upper left corner indicated waaay over 100FPS but felt like 20FPS or less sometimes. It was only until I changed the last setting that I finally solved EVERY stutter – major- as well as the annoying microstutters which brought me true X-Plane nirvana: DISABLING-V-SYNC !!
I thought I had checked that on day one at beta1 as mentioned in that thread but somehow I must have messed up.
Anyway I am SOOOO impressed with the ultimate fluidity (no micro stutters anymore) even when framerates goes below 40 – We are very sensitive to stutters and it actually does not matter if we only get 40 FPS if only we get 40 FPS constantly with no stutters we then perceive it as fluid.
Details on Setup / settings for reference:
Rig: I7-8700K@5GHz, GTX1080 8GB, 32GB 3600MHz CL15 Ram, NVME SSD´s. ASUS 2560×1440 144KHz G-.Sync.
X-Plane 11.50Beta4, X-Europe 5; Sim Objects; Orthos @ zl16
Settings: Visual Effects: High(HDR); Texture Quality:Maximum; Antialiasing: 4xSSA+FXAA; Shadows on Scenery:ON; World Objects: MAX; Reflections: Medium; Draw parked Aircraft: ON; Vulkan ON aaaaand the magic one: V-SYNC OFF 😀
All other options and settings are standard vanilla.
Laminar – what a good job! – you are on a homerun here 😀
Thanks
I upgaded to b4 yesterday afternoon and reported a crash after less than an hour of my first test flight. Later in the evening I Tried again after moving the LUA and Advanced Rendering plug-ins into a holding folder where they won’t load and successfully flew for over three hours.
I’m also seeing the cloud base shading flicker and overall edge jaggedness – which I assume was just a recalibration of the anti-aliasing code.
This was on my mid 2014 Macboook Pro. I’ll try on the 2010 Mac Pro today.
An, thanks I read that post when it came out and commented on it actually. I read the phases of development and priority for releasing beta builds. My question is around the micro-stuttering and if it was on the radar to be fixed. I guess I should have not used the term ‘blurry’ to describe my issue. It is more like… double vision. Like an exact copy of an image 1mm or so away from the first. Like looking at the MCP and the digital numbers for speed/altitude. When you move your head, it’s like the numbers get double-visioned and shake/micro-stutter. Not really blurry. More like stutter-y.
So I guess my questions is – are there plans in the 11.50 development/beta/release roadmap to address this kind of micro-stutter?
Again, I have filed defects using the bug reporter, so I don’t expect this to be an official defect report. Just a finding I wanted to share in the developer blog comments to see if others testing the beta have experienced anything like it. And maybe to see if one of the developers could comment on plans to address it.
Thanks, all!
I just wanted to comment that the performance gains greatly surpassed my expectations! Especially taking into consideration that I’m an nVidia user, and I am GPU limited (I’m running an i7-9700k and a GTX1070). Still, I easily get a 20% increase and a very smooth experience. After basically 2 years waiting, at least it wasn’t for nothing! Good job!
GTX 1070 is little …?. What a shame!!. Here, in this detail is where it is shown if the created program is good or bad and it suffers from good things and others very poor … Little by little it is fixing and others spoiling such as aliasing, blinking shadows, terrain microgranules and flickering lines … And here comes the “funny” part of this software, GPU CORE hardly touches it and eats graphic memory, so what good is it to have GTX 1080 if you only have 8 GB. What do you want, that you “buy” 2080 you …? over $ 1,200. Embarrassing the pipelines
Hi Guys
Just wanted to say how great this update to 11.50 is for me, yeah I’ve had some crashes but the overall VR flying experience is awesome, keep up the great work things can only get better.
A big thumbs up from me.
Cheers
PS. My System GTX1080ti, 16gb Ram (nothing special) and a AMD Bulldozer 8150 oc to 4.2 ghz
Switching to wireframe in Planemaker with Vulkan enabled still throws a null pipeline for me.
Is it normal that I get about 30% less FPS in fullscreen mode compared to windowed mode (using 1440p for X-Plane in both cases) – both with Vulkan and OpenGL (on macOS)? Since the pixel count is the same, I expected a similar FPS for both modes with slightly higher for fullscreen mode because other apps are hidden.
I’m curious about this as well.
I observed the same … turning off vsync and running in windowed mode made the difference between stuttery 20 fps and 30 smooth.
I am on 11.41 , nvidia 980, i7 , 64 G of RAM, 8 G on the card. 2560×1440 res, no scenery shadows
11.50b3 and b4 has been working fantastically for me, even with 3rd party heavyweights like JARdesign A320 and Zibo 737. Frame rates and smoothness with AMD card catapulted though now I am being CPU limited. I guess 3rd gen i7 is ‘old’ but overclocked to 4GHz I am getting fps to stay at or above 30 in the densest situations.
Still have cloud flicker going on
Running on:
intel i7 3930k o’ced to 4Ghz
16gb ddr 3 ram
AMD Radeon RX 5700 8GB
Windows 10
Anybody else having xp11 not showing 3rd party aircraft in the selection after b4?
Never mind, stupid error regarding duplicate x plane folders.
LR- don’t even think of Final until, shadow jaggies, cloud flickering and black smoke are All fixed!!
Also please address extended draw distance (blurry horizon) issues.
Doug.
Not to mention the in flight command buffers issue, the application hanging when trying to alter the window size or switch to full screen with complex scenery loaded (nothing to do with plugins) or the gradual fall in frame rates over time. We are a way from seeing a final releaser version at this point in time.
An update to the aircraft prevented the X-Plane 11.50b4 (vulkan) from starting. I sent it through the error report. Sorry to post here. However, I see Laminar working so hard to improve the X-Plane that I felt compelled to report that a poorly written add-on can cause an error of this magnitude. Thank you for the excellent work of all of you.
The performance with my Pimax 5k+ Headset is still disappointing and seems worse than in the 11.41 version. I had already reported this under the Beta 3 version and was hoping to get an improvement with Beta 4. Two things improved though: the VR mouse cursor is as precise as in 11.41 now, and X-plane seems to crash less often (which is why I didnt send another bug report). But what still strikes me is that that GPU time is very low with 0,0002 while CPU time is around 0,0646. With my limited technical understanding, I understand this means that the low FPS are related to the GPU and not the CPU. This is surprising as I have RTX 2080 (and i7 9700k). Rendering options are medium on average and with no clouds.
Your understanding of the frame time is backward. The frame time indicates how much time (in seconds) the CPU or GPU require to complete their workload. The component with the greatest frame time is your bottleneck. If you divide 1 second by your frame time then you can see what your frame rate should be. Your CPU is limiting your frame rate to 15.5 fps (1 / 0.0646) while your CPU would happily run at 5000 fps (1 / 0.0002) if the CPU wasn’t your bottleneck. This means that you should turn down the settings in the right column (world objects, reflections) to increase your frame rate. Conversely, you can turn up the items in the left column (lighting, textures, AA and scenery shadows) to get more eye candy without a change in frame rate. Ideally your CPU and GPU frame time should be close to each other so that neither component is the bottleneck.
You would probably see a performance improvement as well if your CPU would tolerate some overclocking.
Thank you very much! Excellent explanation!!!
Thanks for the excellent explanation!
Nevertheless, I am pretty sure that the bottleneck in my case is the GPU as textures of scenery and runway are very poor, and lowering the right-side CPU rendering options doesn’t result in a significant improvement.
Sorry to hear that, my performance with the Pimax are exactly the opposite to yours and somewhat lower specs.
FPS are much better and consistant, I can sometime use clouds and still enjoy the flight in VR (yeh, shocking ).
Thee are some issues like reflecrion and cooling effects for larger than normal FOV headsets.
Overall, impressive bump from my machine.
Hi Ben,
I have some weird issue, every time in the same area same conditions the fps difference is around 60-70% , let’s say i load a flight at VAJJ in the vFlyte AA5 (for e.g) where i will see around 25-30 , then if i shut XP and reload the same scenario it will be stuck to 11 fps and i have seen it go to 8. Even with flat orthos is the same where there no buildings or any other objects.
Most of the time its at 30 , i was surprised that with Objects set to HIGH i am pulling 30 fps over NY on my system.
I am not sure what is the cause of this. Is it due to 2GB VRAM or is it that the VRAM after shutting XP is not freeing up ?
The area that i sim is using Ortho4xp , with textures set to MEDIUM.
Of course my system is not even mid level so i can’t place if its system related or some tweaks that would be needed in vulkan from you.
AMD FX 4300
RX 550 2B
12 GB DDR3
I was going to order a new system but as we know we are in a lockdown.
If you need the logs please let me know.
Rgds.
Zulfikar
I am just curious … how long does it usually take between the start of public beta testing and the release of the final (non-beta) version with X-plane? Or is there any forecast when it may be ready (and I know that this can only be a tentative forecast)? Forgive my impatience but I am so eager to fly with the final, hopefully bug-free version with my Pimax 5k+!
And thanks very much for all your efforts! X-plane means a lot to me
The short answer is: It depends on how many bugs are found and how difficult they are to fix.
The long answer is: It depends on how many bugs are found and how difficult they are to fix. Due to the nature of this particular update (a complete rewrite of the rendering system), expect a long beta period. The devs have said that 11.50 beta will be lengthy, and the alpha period stretched on for months because they realized they had to completely rewrite some of their code (multiple times) to fix a problem. There’s a high probability that that’ll happen again.
So, you’ll have to be patient. Or, download the beta and try it out. The best way to help them get as close to bug-free (no such thing) as possible is to find and REPORT bugs and crashes.
There really is no way to compare length of beta cycles. This one is probably going to be a lot longer since it is a complete rewrite of the core graphics system. LR is focused on three areas, prioritized as follows:
1. Stability – system or program crashes MUST be addressed early on in the cycle as well as making sure it is all usable.
2. Performance – getting the VRAM usage/management optimized and other performance enhancements squeezed out of all the possible hardware combinations out there.
3. Visuals – making sure that everything LOOKS good once it is all running smooth and crash-free.
Right now, the betas have been addressing concerns in area 1 above. This includes the VR mouse issue that was addressed in beta 4 – a usability issue. The beta cycle started just over 2 weeks ago and things have moved along quite nicely on addressing crash issues but some do still exist.
I believe work HAS been going on in the background on the other 2 areas but this is as time permits while focusing on stability.
If you’re really wanting to experience what Vulkan/Metal have to offer, go ahead and make a second copy of your X-Plane installation, update that copy to the beta and participate in the testing. You can still fly the stable 11.41 version for a (mostly) error-free platform and at the same time help make 11.50 the bug-free version you’d like it to become. That way you’ll have the satisfaction of saying “I had a part in that !” when the final version does get released and not “how did this make it through the beta testing?”
The VR mouse correction made all the difference. Really made it possible to enjoy flying again without having to lean back/forward every time a control or switch needed moving.
A small, albeit much requested feature in 11.50, would be an ATC respond button. Using a mouse for ATC when on on manual short final is far from helpful, even though we’ve had the problem for years lol.
I am just sooooo impressed by the XP team. Vulcan has made a huge positive difference to the stuttering problem, especially in VR (Oculus CV1).
When combined with sensible config edits (birds etc) in order to save unnecessary VRAM and FPS resource wastage, the results are impressive. This is the first time in years I have been able to enjoy XP in smooth, almost stutter-free VR.
Thank you all so much.
(i7, GTX1080, 16Gb RAM, SSD, Windows 10)
Finally got 11.50b4 Vulkan running on my Linux system, with “RADV_PERFTEST=aco” the shader compiles really fast with AMD drivers coming with Linux kernel 5.5 and mesa 20.0.4, actually I didn’t even notice them compiling.
With all graphics settings maxed out I get almost no benefit from Vulkan (21 fps) against OpenGL (20.5 fps), but when lowering AA settings 2 or 3 notches and number of objects one notch, I get an astonishing 70-80 fps on Vulkan, vs. 35 to 40 fps on OpenGL.
This is on Radeon Vega 64, AMD Threadripper 2nd Gen CPU and 3200 MHz memory and 1920×1080 resolution.
On the downside almost none of my plugins work, neither do most 3rd party aircrafts. The SASL plugins coming with them and just about anything 3rd party that attempts to draw on the screen make X-Plane crash.
Don’t understand that. Even running Xlife at Aerosoft EGLC I’m getting smooth VR. Objects on High, reflections/shadows off, and no AA (it makes no difference in VR) etc. Overall, Vulcan is like some miracle cure for me.
(i7, GTX1080, 16Gb RAM, SSD, Windows 10)
Crash after crash unfortunately. I am flying on laptop – dont expect any graphics – but on 11.40 it was flyable on low graphics (and lot of fun), since turning to vulcan this is another beta when open gl and vulcan mode are crashing when loading the flight or just after starting the flight.
This is not a bug report.
Please change the default value for the art daataref clouds/limit_far from 1.0 to 0.5 (or thereabouts)
It greatly reduces if not completely fixes the cloud ground shadow flicker bug I’m sure is filling up the bug reporter.
Other than that, great job.
I am working on tuning for the clouds that is very similar to this and has similar effects in terms of cloud stability.
Excellent. In other news I just finished first testing of xtlua (your xlua only in its own thread).
still some more todo but the few test scripts I threw at it today (such as printing 200000 lines in a loop while getting/setting a string data ref and multiplying some float datarefs) only started touching framerate when I maxed out the cpu.
quite a few things I want to do with it, hope others find it useful to. I’ll put the fork and branch up on github when I wake up.
Exciting times, even if the world is ending.
Cool – that’s a great extension to see. Just to confirm, XTLua is NOT calling any XPLM APIs from the worker thread, right? Often the trickiest part of threading plugin code is inventing an async way of interacting with the sim.
Only XPLM commands it “should” be making are from a mutex locked “xtluaDefs.updateDataRefs()” called from the old xlua_dref_postUpdate. That gets if they were got and not set, and sets if they were set.
I say should, because I haven’t yet cleaned up XPluginReceiveMessage for example so defining an aircraft_unload function in the lua will do bad things at the moment.
I’d quite like to link XPLMInstance in there to – but one step at a time.
Hmmmm – this doesn’t seem safe. You can’t call a plugin function from a worker thread, _even_ if you can ensure that you have blocked the main thread inside your callback (via a mutex). It’s still an API violation (and a bad idea because you’ve blocked the main thread.
What you need to do is use a message queue to ‘send’ the data between the worker and the main thread…that way the resulting datarefs get picked up whenever the main thread is ready for them without blocking.
All the lua is moved inside, created and runs in a worker thread, that gets and sets objects inside xtluaDefs and runs asynchronously (No awareness of XPLM)
once each flightmodel frame via registered flight loop, xlua_dref_postUpdate blocks the lua thread by calling updateDataRefs(), this makes the actual XPLM calls, synchronising whats in xtluaDefs with X-Plane. if Lua got a value and didn’t set it (e.g. wants airspeed), that is set (copied into) the xtluaDefs object, if Lua set a value that is set (copied into) in xplane. get and set flags cleared each call to updateDataRefs()
only floats and strings at the moment
initial commit is on https://github.com/mSparks43/XLua/tree/xTLua
Only built on Linux atm (and no idea about how mobile handles std::thread) commands probably also need stripping out (but no need to run them async anyway as far as I can see)
Should be enough to copy the contents of the deploy folder into an aircraft plugins directory to see it working, just need to check the git is up to date and share it. There’s a learning curve to pass on building systems with it (going to start by rewriting the 747 systems with it for the YA747)
Hi Mark,
Right – this strategy (where you’ve coded it) is legal. The one tricky thing is: if you take the lock a lot in the script side (momentarily) and you need the lock to do the per-frame IO, you could end up blocking in the frame callback. This is why I prefer message-based systems – the data ownership is _transferred_ and thus doesn’t need a mutex – you own it until you put it in the mailbox, then when it gets picked up, the recipient owns it. In this kind of model, you’d “mail” dataref changes to the main thread. We use this extensively in X-Plane itself to have a lock-free design wherever possible.
->you could end up blocking in the frame callback
shouldn’t block meaningfully, because from lua only the gets and sets are locked
so during
xtlua_async_string = “lua” .. ref
the flightloop is only blocked as lua copies the string into the store via XTSetDatab (or the lua blocks until after synchronisation if the flightloop is already in there)
From a usage perspective it will need watching for inconsistency, because no guarantee two visually sequential gets in lua will return the same value if XP is setting them.
The locking object is a single class
https://github.com/mSparks43/XLua/blob/xTLua/src/xpmtdatarefs.cpp
I did a more messaging approach for resolving the drefs, where lua pushes into a vector drefs it needs resolved then the flight loop resolves them before allowing the worker thread to start making before/after calls. Something similar will probably be needed to support function calls on sets/gets if they end up being required.
the get/set flags are used to limit it to only those drefs which have been touched between synchronizsations (and thinking about it, sets should only be when touched and changed).
it’ll evolve if/as it gets used, really needed it to start doing some heavy lifting for the 747 FMS without killing framerates. my next task is to actually familiarise myself with lua some more.
I also linked it on the org
https://forums.x-plane.org/index.php?/forums/topic/209883-xtlua-parallel-lua-for-complex-aircraft-systems/
Is Vulcan go on my PC:
Intel Core I5 7800
MSI GeForce GTX 1060 6GB GDDR5 OCV1
RAM 16GB?
If you mean just can you run it then it should be OK. I have a 1050 with less ram and it runs. Although LR is working on -out of VRAM- issues, Cards with 6gb or more tend to have few if any issues of running out of VRAM.
Although I see many people completing full flights with it… i suggest that you install the beta on its own install and just use it for less serious (ie dont use FSEconomy ) test flights. Expect early beta buginess.
If you just want to install as your only sim with no backup then then wait for later betas or even the full release.
I have a 2080 TI with 11 GB VRAM and Vulkan reduces my textures with my addons. I really hope the new 3080 will have more VRAM when it comes out later this year. Will have to get one to enjoy X-Plane!
I have heard this from someone else with a 2080ti. I think its the VRAM memory issues. (it has been called a bug) The VRAM issues do not cause the sim to close like on low memory cards but they do cause big memory cards to lower textures when they shouldnt have to .
This is something they intend to address.
Get a 3080 if you want (nvidia will love you) but the 2080 ti 11gb should be plenty for a long time.
Probably will have to wait a few more betas tho….
With Vsync on, running under Linux, I find limiting fps to 60 gives a much smoother experience with far fewer micro-stutters than letting X-Plane run at the speed of my 100 Hz monitor.
Note I limit fps to 60 by using the “–lock_fr=60” command line parameter for X-Plane. I have kept the monitor running at 100 Hz.
I have been testing Linux Vulkan VR since I had the pleasure to be included with the early testing team. During that time I was getting some unexplained CTD, desktop lockup and not being able to start a new application and think I have found my issue.
In trying to find the root cause I have been running X-Plane with gdb and looking at the Web logs from SteamVR and find one common error that was “too many open files”. I have since increased my ulimit from 16000 to 65000 and in my testing over the last days have not had any of the previous issues.
I am posting here to make sure that none of my previous bug reports were polluted by this issue. Now my Linux install is as stable as my Windows which makes me very happy.
Thanks Bill
Interesting. Running out of file descriptors implies something is opening files but not closing them. Laminar Research might want to do a code review and make sure they always close the files they open.
My three basic mantras as a software developer were “every open deserves a close”, “every allocation deserves a free” and “check all allocations against NULL.”
When this was going on I had much more that X-Plane open. I had SteamVR, Firefox, OBS Studio, Godot and probably a few more that I do not remember right now. You might be right but to find the correct program that might be a blame was not my reason for posting.
I did a quick Linux flight around Honolulu in my BD-5J while monitoring the number of open file descriptors X-Plane had allocated, checked every ten seconds. It started at 306 at the beginning of the flight, rose to 342 after takeoff and remained at 342 for the vast majority of the flight. It went up to 349 upon landing at the same airport I took off from (PHDH). So that doesn’t seem like it’s too crazy, but I wasn’t doing a lot of cross-country either.
Can you let me know how to do that so I can do the same?
Thanks Bill
1. Open a terminal.
2. Run X-Plane.
3. Switch back to the terminal.
4. Enter “ps -efw | grep Plane” to find the process id of X-Plane. The process id will be the first number after your user name. For this example, assume “555” is the process number of X-Plane.
5. Enter the following to get a count of open file descriptors every ten seconds for process “555”:
while true; do ls -1 /proc/555/fd/ | wc -l; sleep 10; done
big problem xplane 50b4 with “regenerate the icons”, in the developer section the dashboards remain black. I restart an update.
Now where Vulkan is alive, you got the chance to implement “truesky” as P3d v5 did and make an end with that crappy sky and with dozen of 3third party weather enhancements. Please think about otherwise…. I dont know.
There is no doubt that this is a great sim, I love it, it’s fantastic but surely you should be pushing current gen GPU’s to their absolute limits? My 2080ti barely even gets hot with or without vulkan, how is this possible? What I mean is, for example, go try play a graphically intense ‘off topic game’ such as COD:MW and your GPU and CPU are on fire, working hard! That’s pushing new gen hardware to its limits… I just feel a bit disappointed that you could get a whole lot more graphical detail in this sim and more performance. I hope that’s the plan? What I’m saying is that there aint much difference in performance with a £500 PC or one which costs 5k at the moment, the margin is small.
I agree with GPU, there is a lot room, but I disagree with CPU. Cpu around 30-45 is much enough, I dont want to have my CPU on fire and CPU’s shouldn’t get to high Temps over long time. In my case CPU at around 40-45 % with an average temp about 50-55 C degree are much enough for a long Life.
That’s my thoughts too, I mean I’d like to think they could change things to make the GPU take more of the load, to even the balance, so to speak. I can afford a decent PC and a 2080ti and I’m not rich by any means, it’s called a credit card and upgrades over time (for me) which is also inevitable with technology, most people I see and read about that play this seem to be real world pilots etc on at least 5x my wage, so they can afford the hardware without breaking a sweat. I just think they should aim for mobile and windows, that’s where the money is. I’ve used Linux, hated the Mac and anything to do with overpriced Apple. As I’m into Web Development/graphic design, 3D rendering and music, you’d think I’d love the Mac but still hate it, I’ve tried the hackintosh thing, I didn’t get along with it, that’s why I like Android & Windows, you can tweak things unlike an iPhone+Mac, plus they hold both a very small proportion of gamers/simmers. Prove me wrong on the last bit, I see that as wasted development time.
In the IVAO y cant see the aircraft
Hello,
Linux Ubuntu 20.04 here, ELF32 bug is still present on steam, and there’s still microstutters (using vulkan)
Already reported a bug, just here to let you know
Vatsim have upgraded their xPilot software to work with Vulkan, and it does so very well so far.
It appears that although the tags BAW123 EAAL7678 etc are getting there, and planes are visible, they only show generic Airbus and Boeing liveries.
Might this be a “clog” in the information data packets transferred by 11.50beta?
I’m not sure if this is a bug per say, as It may be xPilot not reading the livery info correctly (Although I did see Concorde sporting the correct clothing yesterday.
My experience with peer to peer networking and sporadic livery exchange fuels these worries..
b4 is all stable here so experimenting with all other “must have” services.
Supporting your great work as always. Thanks
update today of a Geforce gtx 1070 nvidia in Version 442.92 at “20-04 23h”. here is the following message: Encourtered Vulkan device loss error “x plane cannot continue running and will now quit. vkQueueSubmit (queue, 1, & info, fence) Please report this to Laminar Research
As an experiment on Mac I locked the FPS with the command line option “–lock_fps=30” and found 11.50b4 spent less time hunting (for want of a better word) up and down in its FPS output at busy airports and panning seemed a lot smoother. Is this possible or am I dreaming? 🙂
Hi LR
Loving Vulkan very much. Even my HP Spectre Laptop runs it realy beautifully when I force it to use the Radeon card and not the Intel. Oh and also it has to be on mains power or the thing is like a slide show. Worked that out after a lot of messing about with settings, then I realised, plugged it in and wow it “took off”.
On the main Sim PC which is I9 9700k OC’d to 5Ghx, 1080TI OC’d and 32Gb DDR 4 with XPlane and ORBX True Earth on an SSD every time I load my second copy of xplane I installed to keep my main copy safe, it says there is the new beta, it downloads the installer, crashes, I stop Xplane in Task Manager then the update screen appears, scans the files and says I have the latest which I dont, as it then tells me there is an update when I go back into Xplane again. I am currently on B3 working really well but to get to that from B2, I had to do a reinstall. I am therefore holding off doing my main sim. My main system runs off DVDs rather than a licence Key and to reinstall it wont let me download I have to spend ages putting DVDs in the drive. Any ideas why it tells me about the beta, I have the right options ticked to get it and then it wont let me have it without ditching the install and starting again. On the laptop with the digitl download version, no issues at all….new beta, installs it and just runs. Weird problem folks. Hope you can help
The sim is great though, you really have pulled this one out of the bag. Its going to be a joy to install in my real C152 cockpit once we are at full Release. Till then the desktop version will be used to tinker with Vulkan.
Thanks again LR
JH
Just wanted to say well done! I installed the vulcan beta via Steam last night and flew some great flights with an increase of about 25% FPS on the same settings, and more stable FPS too. This has allowed me to push the sliders to the right, I even have some reflections!! What a difference this has made to X Plane, great work Team Laminar 🙂
Hi… any ETA for Beta 5?
The water is concrete …?. The shadows of the clouds wink at me remarkably, even if I don’t move … Ramón “eso” (lua) is useless. It serves to fix it Laminar investigation. … My colleagues and I are considering abandoning X Plane, because they don’t feel like using the GPU anymore. Sorry but, is good…Sorry it is good, but there is no more work on the GPU … I have i7 4790K (4.4GHz) + GTX 1070 OC + 24GB RAM 1600 CL7 in SSD SAMSUNG EVO 550 and it is fair, scarce. why don’t you want to use the GP more …?
The GPU indicator at 0 is a bug, the GPU is used as usual!
this is the beta, unstable version. You can still use 11.41 stable version as previously, if that suits you more.
And don’t look at the usage of CPU/GPU, but the framerate and stutter free experience.
i actually experience stutter that in the 11.41 I never had.
they’re like small lag because of the continuous change of the frame rate up to 20fps
Just the opposite with my very old machine:
i7 3770k @ 3.5 Ghz w/ 24 Gb ram, Nvidia 1050 ti W/16 Gb video ram, windows 10 and a 2 Tb spinning hard drive.
I just want to say that the xplane team hit a home run with this update. I’ll even go far as to say that I’ve been using 10.50 beta since it came out and have been slowly adding my UPDATED plugins one at a time. Unless something bad happens with the betas, I am never going back to 11.41.
Looking forward to the future with xplane development.
Thank You
First of all…
Like to thank LR for there efforts to always be in the frontline of evolving there flightsimulator. Is a gift for us IRL-pilots that need a “back up” to stay sharp while grounded.
Thank´s to the whole team at LR.
Some feedback..
While this update over all feels like a major step forward with an increase of FPS I do have stutters in some areas while using 11.50B4 with VR. Have a rig with an i9 9900K, 32Gb RAM, RTX2060 super and SSD-discs. Using HP Reverb for VR with all software updated. Have Ortho4XP, X-Europe, several custom airports (mostly freeware) and ASXP running while flying with DF´s Bell 407 XP11 in VR. Graphic settings set to “High” and AA one step up. Most of the time at 30-35 FPS flying at altitudes from ground up to 2000 feet.
Stutters appears while looking around inside the cockpit (turning my head, not changing position), on water areas that suddenly and from time to time appears strange for a short while (completely flat and all black or like textures from nearby buildings or solid ground are “streched” out over the water) and sometimes there´s a big differens in performance when going from a “default area” in to/out from a custom scenery (this includes both lower FPS and stutters).
Bug report will be posted later tonight.
Before my windows box sent you guys an in-VR crash report, I got a real nice short flight between local airports, void of the VR stutters of the past. Nice!
Issue: I approached and landed on the bluriest runway ever (on top of Orbx TE UK south), it got sharp half way through taxiing off it.
Questions about the roadmap of the texture swap algorithm: You have the aircraft polys prioritised over everything else. Will you be prioritising textures of ground polys (or even specifically runways), and then object textures last, with the assumption objects are going to occupy less pixels than ground polys & ortho scenery.
Although, i imagine the ideal algorithm would be based just on screen size, pixel density, and ’how recent’ / likelihood of being needed – is this realistic?
Hi LR team! There are interesting discussions going on at the .org-forums. Main worry is how much VRAM do we realistically need for Vulkan? Or put the other way around: do we need a lot more VRAM to run X-Plane on similar settings as with OGL when switching to Vulkan. Some users belief all the speeding up comes from the fact that now much more stuff is in VRAM. What is the reality here?
Sigh. The reality is:
– X-Plane 11.50 is making lousy decisions about VRAM. We know about a lot of these already. Some are fixed in internal code that is not ready to ship yet.
– I said in a previous post that we were going to focus on crashing first, VRAM second, perf third.
So…the speed is _not_ coming from using more VRAM, it’s coming from the driver being crazy faster, plus perf fixes put into X-Plane. But the blurries and high VRAM usage are coming from poor decisions.
This will be addressed in a later beta, but Sidney spent all of the time between b4 and the upcoming b5 focusing on crashes.
It’s really too soon to speculate on needing new hardware, and planning new hardware based on an early beta is unwise.
I disable SearcUI (Cortana) in Win10 and it returns me to the desktop. The cloud shadows pound and it becomes unbearable. The GPU is underutilized and eating too much VRAM. The choppy and flickering lines of the scenery terrain … I think that the Microsoft with Cortana will cause me to leave the simulation … Or I go to Linux Mint … It makes me suspect that, … you did not implement it for Windows 7, which looks better and better sound… Puff!
can you guys explain the changes to the reflections slider? like you have 2 notches that say Medium… what does that mean? what changes for each step of the slider?
is it only me that experience very inconsistent frame rate?
I mean the FPS are very good now in my mcbp 2017. But… there are continuous jumps of frame rate like from 32 to 25, from 45 to 30 etc etc like big jumps and all this make the sim luggish…
I have nothing installed as plugins and I’m using the original planes the sim comes with
Exact. To all of us who use X Plane 11.50 in Vulkan. Not in OpenGL. Heavy scenaries have been greatly improved in Vulkan. They already warned that there would be a lot of stuttering. They will have to fix it and the shadows with a lot of flickering and aliasing
I have tried the betas but none of them has adressed my issue.I have a ryzen 5 2600 with an rx580. Usually I get butter frames on most games but here there is a problem in X-plane. My gpu is pushed to 60-80% while the cpu stays between 15-30%. Usually that would mean that the gpu is the bottleneck but actually the cpu has 0.05 frame times while the gpu stays way lower around 0.015. The cpu usage is low even though the game is demanding the resources. Could someone at laminar have a look? It’s ruining my flying experience specially on areas with hd meshes.
Obviously your GPU is insufficient. Minimum for X Plane with Vulkan (betas) RX 5700 Gaming X 8GB GDDR6 or GTX 1080. Anything below this will have micro-stutters, in low refresh rate displays and 1080p … + – 400 to 600 € of graphics
Those are _not_ the GPU requirements for the beta, and they are higher than every GPU I own.
frequent message on Xp 50b4: “why do we have so many in flight command buffets? m_inflight_command_buffers.size <= 100 »My GeForce gtx 1070 nvidia 442.92 card. Jonathan