Spicysauced

To my knowledge it isn't possible for an external program to "sniff" a program's actual usage. It sees "program X has requested and gotten Y GB", but it does not see what "program x" actually uses. Allocation ≠ usage. -> https://forums.tomshardware.com/threads/any-programs-that-show-vram-usage-not-allocation-vram-allocation-is-not-vram-usage.3664582/ I'm happy to be corrected on that matter, but I think this is still the case. Only the program in question can see itself. Qcumber has a point there. It would be interesting to know what DCS actually does, and that's indeed visible via the overlay, completely forgot about that. So, tested again, of course with workaround still in place (Contention, Hind, Damgarten airport this time): Task Manager says allocated 7.3 Gb, DCS says 4.4 GB actually used. I can definitely live with that. So to conclude: The workaround saves both on allocation and actual usage.

Let me add one more thing that I didn't mention before. If you have a card with 8, 10 or 12 GB of VRAM you have surely noticed that DCS fully pegs that storage. I don't know how it is for card with even more VRAM but from what I've seen even very high amounts are "utilized" fully. Limiting the hard-coded precaching with my solution leads to reduced VRAM load, see picture. This is on Contention, on the Germany map, in a Hind, with OBS and Discord running. You can see 6.4 GB of 8 GB used. Now there is the fraction of people saying unused (V)RAM is bad RAM. But I only partly agree. While (V)RAM is indeed the fastest memory in your computer, and utilizing it is good when done efficiently, we all know too well, that DCS does a lot of things, but what it surely doesn't do is to use hardware resources efficiently. In these bottlenecked cases, may they be caused by engine-related inefficiencies, or map bugs, pegged (V)RAM takes "breathing room" away for the system to deal with said issues. Since I have now played extensively with my workaround applied, about 7 hrs of online gameplay, and the stuttering hasn't returned yet, I'm close to calling it a day regarding the issue. The bug is obviously still there, and needs to be fixed, but as I already pointed out on the Discord thread related to the bug, the ball is now in ED's or Ugra's court. We as users can't do more. For anyone who comes across the issue, and to this thread via Google or otherwise, please apply my, as well as Kiwi_Viper's workarounds, and you should be at least better off than before, in the best case you won't see any stutter at all anymore.

Thanks @Kiwi_Viper, that's in interesting approach for sure. I think what happens here is, that forcing ReBar on also forces better interaction between VRAM and RAM. Since I'm currently happy with the "solution" aka workaround posted above, I'm a bit afraid to try this and break things again, but if someone else could chip in and test it thoroughly I'd be very thankful, also my curiosity would be satisfied Additional thought: If that works for more people, it would mean that ReBar isn't actually on in DCS despite it being on in BIOS and driver. You're absolutely correct too about ReBar only being available on RTX3000 and up. Unfortunately I have no idea how that would work for AMD users.

Another try. Could we test the following? Navigate to \YourDCSFolder\Config\graphics.lua Make a backup of that file. Then in that file, navigate to Precaching = { around_camera = 50000; around_objects = 10000; around_types = {"world", "point"}; preload_types = {"map", "world", "mission"}; Change the values to Precaching = { around_camera = 10000; around_objects = 5000; around_types = {"world", "point"}; preload_types = {"map", "world", "mission"}; That reduced the precaching values around objects and camera, as it says on the tin. It's independent from preload radius in the options menu. Changing these values does not break Integrity Check. I have limited time to test, but I quickly hopped on Contention and saved about 7 GB of RAM with no stuttering in the north, but that was just one test and does not mean much. Also, sadly, DCS's engine always reserves all available VRAM, meaning the actual VRAM usage is hidden from the user, but it is an attempt to reduce the system load independently of the options offered in the graphical user interface. Could you test in scenarios that definitely caused stutter before and report back?

Ridiculous indeed. I am still failing to see commonalities of the affected systems. They seem to widely differ. Everything from a 3060 up to a 4090, 32 and 64 gb, even a person with 128 gb complained under my video. Also the processors seem to differ, AMD as well as Intel systems are affected. So as a conclusion, I don't think it's related to a specific sytem component. Possible reasons why your mates think they aren't affected (just off the top of my head): - They werent far enough north - They were up north but only looked south, then died and only played a short amount of time (for example) - They are playing on very low settings, masking the problem. The FPS would still dip, but only from, say, 200 to 60-ish - They are "immune" to FPS dips, not being bothered. I've seen several people, especially VR users, saying "Yeah I'm fine with like 45 FPS". That could play a role. Quote from the forums I've finally managed to get a reasonably stable 45FPS in multiplayer and would like to share my experience with you All this and more could play a role. At this point, I think everyone is affected, but they either didn't notice or aren't bothered. I'm of course happy to be convinced of the opposite.

The question is, would that have helped on your original drivers too. We can only go into the driver related direction, if with your original drivers, that would not have helped. Then we would have an indication of something in newer drivers causing a performance degradation. So: 572.83 - 4 x ALT TAB causes performance to go back up i.e. 576.15 - 4 x ALT TAB does nothing I am still convinced that it's a map issue, because even IF the outcome is as described above, performance on ALL other maps is still fine/normal, with no alt tabbing needed. Also, a lot of people have been narrowing it down to the norther part of the map, including myself. So, logically, if the south is completely fine (like other maps) but then suddenly in the north your driver begins to matter, it would still point to a map related bug. Very likely a texture thing, thats using way more vram than expected/needed. A rougue grass texture that has been used double, on top of each other by accident, as an example.

@MorgothNL I can confirm the issue using your track file. I hope anyone from Ugra or ED responds to this ...

I have made a video to summarize the facts regarding this bug as of today, 24th of April. It's just to raise more awareness. As usual, the more people chip in, the higher the chance of a quick solution.

Hi Bignewy, thank you for checking in. I can only attach a file with max. 50MB here, my replay, although it's just a 2 minute flight is already 62 MB, I don't know why. So instead I uploaded it to file-upload dot net, I hope that's okay: https://www.file-upload.net/download-15486819/CWGermanyStutter.trk.html I accompanied it with a short video, this is the same session that's shown in the .trk file: Now here comes the interesting part: When I play back my own replay file, it comes out perfectly fine. No stutter, nothing. I could not believe my eyes. If I didn't do the video(s), it would look like it never happend Maybe you can test this for yourself? It can be reproduced the easiest by: - choose Hind - Instant action - Choose "Hot Start at Rostock" - Fly/look into the direction of the island pointed out above 2nd easiest solution for reproducing: - Join Contention Cold War - Choose Hind - Choose spawn in the north and look into the island direction So to conclude: - Reproducible 100% of times in single and multi player in the area in question - Does NOT (apparently) show in replays (I cannot think of a reason here) - Multiple planes affected (Hind, Mig21, F16 as proven by Cap from GR), but potentially not all planes (Flanker/FC3/-2024?) - Not bound to a specific GPU or CPU configuration or too bad systems in general, so hardware isn't to blame here - Not RAM bound either, I have 64 GB plus 50 GB Swap - Not affacted by mods (I tested with the black Hind cockpit and with all defaults/stock) - Not affected by head tracking software such as OpenTrack, tested with and without - Many people affected, potentially all, but as usual with bug reports, most remain silent and never check forums - Not affected by preload radius or visible range options, settings those to 0/min still gives stutter This is all the information I have at this point, sorry I can't provide more. I'm afraid this will be hard to troubleshoot, especially since it doesn't seem to show on trk files. Have a nice day and thanks again!

Addition, I did more testing. Flew along the black line, keeping the stutter always in front of me in an effort to find the zone that's causing it. Sometimes I zoomed in all the way to narrow down my "search cone". And I think I found it. It's the northernmost part of the little islands, I put a label down there. The second you go feet wet and fly over the coastline the FPS jump back to normal. So whatever is on that island, it's too much for everything from a 3060 to a 4080 apparently. When flying red side this is particularly awful, because you're basically always in the area that's affected. And yes I tried the usual tricks with deleting fxo, metashaders before. I also checked if preload radius affects it - it doesn't. Even with preload to 0 it still happens. View distance has no effect either. I also tested different vehicles, although not as in depth as with the Hind I used to search in detail. The thing is, in a flanker quick mission where you gen an airstart this didn't happen, and in an F5 it didn't happen either (I wasn't in that exact spot with those, but close). So it did happen in the Mig21 and Hind, it did not happen in the Flanker and F5. So you could make a theory that it depends on the plane you're using. But I put a big question mark behind that theory. I hope Ugra looks into this, its really annoying

I can confirm that. Being north and looking north causes massive FPS drop. Happens online and offline, isn't server/hardware related. Since a lot of others are affected, I think it's a bug. Here's a short video:

Hm, yes I am new here. Vulkan? Well, that would be nice indeed, but a) ED being ED this will not be implemented this year and b) there ARE people like Ralfi, Hellreign etc who can obviously run DCS at max settings. Ive read about the 32 GB Ram recommendation aswell, but this isnt the root of the problem described. Also 32 GB just and only for one game is ridiculous. I dont see the point in paying even more money for my hardware just because a dev cant optimize his game. ANYTHING else runs more than fine, its just DCS. "DCS will only use a single core from your CPU if I'm not mistaken." This was the old engine. Since EDGE/2.X DCS arrived in the year 2010 and supports now 4 cores.

Hi guys, first time posting here. I dont know what the reason is, but I cant get (really) good performance in DCS, it depends a little bit from module to module but its more or less the same all over DCS World. I have a pretty good system, as follows: - 1600X Ryzen @ 3.7 GHz - Vega 56 @1500 - 16 GB Hyper X Fury DDR4 - DCS installed on 1 TB Crucial MX500 SSD What I would like to achieve is, what I can achieve in any other game: Stable 60+ FPS. However, unlike any other game, I have to tune down settings quite a bit. Shadows are making the biggest impact on the performance, if I enable the cockpit shadows I get (depending on the module/airport) 30-50 FPS while my GPU is maybe at 50-60% usage and CPU something like 30-40% max. Also I have to add, that these problems only apply to multiplayer, once I start a training mission etc., I get way higher FPS even with shadows and bells and whistles on. So my guess is, that theres some kind of bottleneck, which cannot be my system, after much fiddling around I think its the game engine(?). I had a look in the task manager aswell while being on the 104th, DCS seems to use 3 Threads only, a fourth one is doing very light work, every other core is sitting idle being bored. These performance problems started with 2.X, never had these before. So are there any (hidden, lua, whatever) settings that Ive missed or is DCS just extremely bad optimized? The settings in the picture Ill include are the ones that I have to use to get my stable 60 FPS. -> https://imgur.com/a/oAuFn36 So ideally, I would like to have full or almost full usage of my GPU and CPU while getting 60+ FPS stable everywhere while having shadows etc on. Any help? Do you guys have similar problems? If yes did you solve them? How? Lets discuss.