I checked that - shared GPU memory as reported by the Task Manager was 5.9GB.
ok, I’ve just added a scenario for you – see my edits above…
Currently in flight in FS2020 - I’ll have to check later.
(Though I’m going through a lot of trouble to try to recreate a bug I’ve never been able to recreate yet, in all the scenarios yet posted).
This a bad airport to load in MSFS2024.
I run it ones and deleted it out of MSFS2024.
It is made for Microsoft Flight Simulator 2020.
Orbx EDDF airport is not realy compatible with MSFS2024.
I’m shutting down FS2020 after my morning flight - I’ll try to gather all the above and make another test in '24. I’ll note that there’s a handcrafted Gaya/Asobo EDDF in '24 already. Are you folks disabling that one when using the Orbx version or do you actually have both loaded at the same time?
It is never a good idea to load an addon airport over an existing one.
Especially not if the existing airport is already a handcrafted airport.
I always delete the existing one if possible.
There is a LOT wrong with this as a test, specifically this right out of the FBW Installer:
FS2024 is DX12-only, AND you’re contradicting FBW’s own recommendations for such a demanding package. Further, 8K textures are just a really, really dumb thing to do in flight sim. It’s throwing raw data-density at the problem of image fidelity in place of numerous other solutions. It’s a very naive, brute-force approach. It’s absolutely going to give any system a tougher time than really necessary.
Also, I haven’t used FSLTL for traffic injection in many months - I used BATC plus models from FS Traffic and FSLTL, but the heavy-lift is done by BATC. I tried to figure out how to run FSLTL for FS2024 but no dice. So that part of the scenario is off the table for me. I also have no clue how/where FBW liveries are these days - not being remotely interested in Airbuses, I’ve never really bothered with anything from FBW before. So house livery it is.
Anyway, with everything set to the Ultra preset, I hit VRAM maximum of >16.1GB and up to 10.1GB showing as shared memory in task manager. Frame rates were as low as 1 FPS when things were settling in, but stabilized in the upper teens to low 20’s without frame gen. Over the next minute or two, VRAM dropped to about 15.5GB.
Messing around with and without Dynamic Quality settings (with a frame rate target of 30 fps) did make a difference - with Dynamic enabled, frame rates were higher and VRAM use lower. With Dynamic disabled, things were a lot more stuttery and frame rates were generally lower, and VRAM tended a bit higher.
Finally, setting everything back to my default of TAA, render scale 100%, mostly high-end preset with volumetric clouds on Ultra, airport and air traffic set to OFF (because I use BATC traffic instead), and VRAM dropped back to around 15GB (5.1GB shared), with frame rates between low 30s and low 40s, without FG.
By contrast, without quitting the sim, loading into the Asobo 787-10 with everything on Ultra preset, I’m seeing about 13.2GB VRAM used, plus 3.6GB shared memory, and frames at between 32 - 35 fps. Again, without FG.
Disabling the Orbx EDDF and going with the Gaya EDDF in the 787, VRAM use is up significantly - 14.1GB plus 4.5GB shared memory. Frame rates remain basically the same. Interestingly, setting my render scale to 200% only increases VRAM usage to about 14.4GB with shared memory of 6.8GB, but utterly crushes my frames (15 fps).
Setting everything back to my usual settings causes VRAM use to drop to about 14GB, and shared memory goes down to 3.6GB.
So for me, the tl;dr here is: I can certainly slam my VRAM and cripple performance. I CANNOT “poison it” such that the sim fails to release memory again.
2 Likes
It’s very easy – just copy the FSLTL folders from the FS2020 Community folder, into the FS2024 Community folder:
…and then just run the usual FSLTL traffic injector once FS2024 is running.
So this confirms you were unable to get it back to zero without rebooting the sim.
https://flightsim.to/file/83904/flybywire-airbus-a380-lufthansa-4k
Yeah, as I said, it wasn’t working. The folders were there but the FBW installer refused to realize it and only gave me the option to “Install” not to launch it.
Um, so? The sim continued to run as normal, VRAM usage went up and down as expected without poisoning itself and performance recovered as expected once I quit out of that ugly 8K whale of an aircraft.
After these experiments, I spawned into the steam gauge C172 in a rural autogen airport. VRAM was 9GB, share GPU memory dropped to 3.4GB. I then made 15 minute flight in heavy overcast and rainshowers up the highway and landed on the main street near my neighborhood. Framerates were as expected 50+ FPS without framegen, and ranging from 100 - 120 fps with.
I’m done with crazy experimentation. My experiments today and as posted throughout the thread show that not everyone suffers from the same problems, even when VRAM is intentionally filled with ridiculous conditions.
Further, these conditions don’t account for people like @Zadma who are having VRAM overflows in stock aircraft and airports.
1 Like
That’s odd. I had no problems installing the injector. Another way is to launch the exe. file in the injector directory. You can create a short cut to it. I never lauch it from the FBW installer. But…FSLTL is not working properly. Planes take off but I haven’t seen any arrivals.
That and the fact Vram usage can change from day to day at the same location with the same settings and so on. I’ve done my share of experimenting and I am done too until SU2 beta.
This is significant. Because more than 640 people have voted here because when this overspill occurs (which stays until you reboot the sim), the sim’s performance tanks.
Or the other way around: “when the performance tanks there is always overspill”.
ie. There is a 1:1 correlation.
I really appreciate your patience as you go through these scenarios, as it really seems like you have hardware that can’t reproduce an issue seemingly most other users have. Do you mind if I offer one additional test case with very specific criteria, so we can have a true 1:1 test of your performance vs mine?
iniBuilds A320neo (Airbus house livery)
Asobo/Gaya KJFK, Gate C 1004
These are the sim’s default settings with my hardware:
Weather and time: Clear skies preset, noon local time
Air traffic: Live
Multiplayer: Off
(obviously standard 1440p resolution will have to suffice if you don’t have an ultrawide display)
And if you could do this test with an unlinked Community folder for science that would be fantastic.
This is my performance if I just wait for download speed to drop to 0 and stand in place but pan the camera around for a few seconds:
If I stop moving the camera, it drops down to the 17GB range and frames go into the 30s, but the second I move again it returns to this. Cockpit view is not significantly better.
You’re mistaking correlation with causation - I’ve been flying in FS2024 (mostly but not exclusively VFR) since the launch. I’ve always had some degree of shared memory showing in Task Manager. The amount of shared memory goes up and down depending on aircraft, terrain, photogrammetry, etc. The presence of that value has never once - not even today - resulted in the a situation where my performance tanked.
Rather, performance tanked when I did something intentionally dumb: loaded into a poorly optimized scenery in a poorly-optimized 8K texture aircraft and then maxed out graphics settings on top of that. And sure - my VRAM and shared GPU memory both increased dramatically and my frame rates were not great. But as soon as I reduced my graphics settings, VRAM and shared GPU memory reduced. And further still, once I exited out of that aircraft and chose another one, using my regular sim settings, VRAM and shared memory reduced right back to their usual range, and performance recovered as expected.
To reiterate: correlation is not causation.
1 Like
Yes, put the texture to the lowest setting and turn off the ray tracing. I have set everything to lowest, goes fast FPS, then added materials back in until it slowed…
1 Like
That’s B.S. because you yourself reported that the shared RAM went down to 3.4GB.
If things really did go back down to normal (as you want us to believe) then it would have gone back down to what it was when you first loaded the sim – 0.1GB of shared RAM (or thereabouts), as it does in FS2020.
Again, you misunderstand correlation for causation: every single time I load into FS2024, there is shared memory showing in use by the sim, no matter how much VRAM is being used. I’m on the loading screen right now, about 50% in, and I’ve got 0.4GB in use already, but only 2.7GB VRAM being used.
I cannot wrap my head around these numbers - I’m using 6-8GB of VRAM on the main menu before a flight is even set up, let alone loaded into. I have never seen usage as low as you’re reporting, ever.
Here you go, default Gaya JFK, default A320neo in the Asobo livery at Gate C1004, everything set to Ultra across the board. Things peaked at about 14.4GB after loading in but have now dropped to more or less steady-state. This is without FG, TAA, render scale 100%.
And again louder for those not paying attention: I always have some degree of shared memory in use even when my VRAM isn’t crammed full.
EDIT: And now after setting my graphics settings back to my usuals, even leaving AI traffic turned on b/c I don’t feel like generating a Simbrief plan just for traffic for this kind of test.
Again, note the presence of shared memory in use despite my VRAM not being full.
I agree with some of this but not all of it:
- Agree on poorly optimised scenery. I will AGAIN reference my previous example of Altenrhein LSZR. It is not a major airport but I can guaranteed go over my RTX4080 S’s VRAM there. This to me is at the heart of the issue.
- In that case a poorly optimised 8K aircraft is not required. I get it in the basic C172.
- Settings: this is really where I disagree. Not the fact that reducing settings avoids the issue, but with the expectation that I have to do this. Sure, I can avoid the issue by cutting back on settings when I fly in a “known bad” location. But this is a matter of realistic expectations of the sim. I have the abovementioned RTX 4080 S with 16GB VRAM, 9800X3D and 64GB RAM. I do not use multiple screens or VR, I typically fly low and slow GA aircraft. My PC therefore handsomely exceed the “Ideal” specs and my use case is moderate. I therefore expect to run close to maximum settings and get at least reasonable results. If I do not get that, I am not being “intentionally dumb”: the onus is on MS/Asobo to eliminate the problem.
The issue is clear: I have problems at a relatively small, clearly poorly optimised handcrafted airport without excessive traffic while I do NOT have it at a major, clearly reasonably optimised handcrafted airport (EGLL) with crazy levels of traffic. And the problem exhibits in a terrible form: it is not just that I get stutters or low-ish frame rates: the sim very nearly grinds to a halt with like 5FPS and significant, crippling pauses where it ignores any inputs.
We can talk about the extent of the problem: I have no problem with that. Even though I think the matter has been beaten to death.
BUT
Many people have clearly demonstrated a reproducible problem. MS/Asobo have accepted that they have a problem and that they will (attempt to?) fix it. To me this means the presence of a problem is no longer a matter of debate. Now I just wait for the fix.
2 Likes
Exactly. I wish the Herr Doktor would see that too 