Jump to content

Constant HDD re-loading of textures due to max VRAM?


Worrazen

Recommended Posts

Hello

 

I wanted to make sure before I make any conclusions, so I made this video instead now, of something else I wanted to post.

 

I kinda dig deep into it, made a ton of notes, then I figure out I need to check and I see VRAM quite high there, this card has 2 GB max. (2048 MB)

 

But thing's have moved fast in recent days, I finalized my decison for a new monitor, and then also for the new GPU, and the new one will be RX 480 8GB well enough to see if the game is really unoptimized and is trying to load from HDD instead or from RAM.

 

But this won't happen for at least a week or 2 until I get the GPU and the Monitor, I was already in the middle of performance diagnosing today (multitasking on this temp monitor hehe) so I just made this video in the meantime for anyone else to give his opinion.

 

 

However the other discovery that the game is fetching obsolete files, is still kinda holding, a lot of queries during gameplay are trying to locate nonexistent files in nonexistent paths, but the biggest part is the GUI, highlighting buttons, but I won't include those findings here right now(which I think devs already know anyway, but just to point it out)

 

The whole video is a bit longer has some figuring out at first, I did it late, just skip to 11:10 , I forgot to set the procmon filters correctly, as well as setting it on-top and gpuz too.

 

EDIT; This is not for nothing actually, it's a control case, yes I could have simply waited for the new GPU and do the video later, the point is I'll do another one and then compare it to see if it's any different.


Edited by NineLine

Modules: A-10C I/II, F/A-18C, Mig-21Bis, M-2000C, AJS-37, Spitfire LF Mk. IX, P-47, FC3, SC, CA, WW2AP, CE2. Terrains: NTTR, Normandy, Persian Gulf, Syria

 

Link to comment
Share on other sites

Hmm, I'm getting an "An error occurred. Please try again later"

 

Will check it out tomorrow.

hsb

HW Spec in Spoiler

---

 

i7-10700K Direct-To-Die/OC'ed to 5.1GHz, MSI Z490 MB, 32GB DDR4 3200MHz, EVGA 2080 Ti FTW3, NVMe+SSD, Win 10 x64 Pro, MFG, Warthog, TM MFDs, Komodo Huey set, Rverbe G1

 

Link to comment
Share on other sites

Having another look at it after several days I have come to an additional observation which may give more chances of my earlier findings staying true.

 

The initial idea was testing to see how good the data is kept in memory , that's a big thread that I never posted because of the VRAM possible bottleneck being in the way of a proper genuine test, it's a factor that has to be eliminated.

 

Now, even if VRAM bottleneck in this case will be the issue in some fashion, and the game has to cycle shared RAM constantly (GPU reserved memory on Main RAM), why does it need to load it from HDD to Main RAM and then to the VRAM back and forth

 

So, the game's still reading from HDD even while VRAM and Shared RAM cycling doesn't really need the HDD if you load all that into Main RAM and keep it there properly, right.

 

So if the behavior stays the same, while the final bottleneck is eliminated, it's going to be a proper game bug and pretty much won't ever get better until it's fixed by developers.

 

 

 

Hmm, I'm getting an "An error occurred. Please try again later"

 

Will check it out tomorrow.

 

 

 

Yes, some cache problem, I have a TamperMonkey script that disables youtube embeds and replaces them with a screenshot-hyperling and a title and it's still showing as "private-removed" the video was too long, it was refused, I had to verify the account by phone to get higher limit, then I activated the video.

 

But otherwise it's working normally, make sure you open it fully in another window on youtube, not through embedds, if it's still not working I'll reupload.

 

I got the new monitor very quickly, but no GPU yet, but plans changed, didn't order it yet, next month probably when funds will allow.

 

 

Here's a normal link: https://www.youtube.com/watch?v=wZf-dsXZGEo

 

I use chrome to view and I'm never logged-in in chrome and it works for me.


Edited by Worrazen

Modules: A-10C I/II, F/A-18C, Mig-21Bis, M-2000C, AJS-37, Spitfire LF Mk. IX, P-47, FC3, SC, CA, WW2AP, CE2. Terrains: NTTR, Normandy, Persian Gulf, Syria

 

Link to comment
Share on other sites

Hehe, oops, I actually recalled to display verbose technical info in DCS with that key combo and it shows "video mem" as ~3900 MB, then it goes up to 4000s and finally 5444MB when I finished cycling through the airfield cameras.

 

EDIT: This could be total VRAM and GPU RESERVED SYS RAM that's being used, because it just seem quite of a high number.

 

That could mean let's say almost 3 GB is shared on RAM and the 2 GB on VRAM that would make up the 5GB total I see reported in DCS diag info - GPU-Z Reports a measly ~200 MB of shared memory whatever that means, can't be right, maybe the amount currently exchanged.

 

But unless I don't cycle airfields and airplanes and move the view around heavily I don't seem to get some of the RAM and VRAM swap issues of any kind and stable FPS, or I just don't know the symptoms to be able to notice them.

 

This whole testing would be going in another direction if my original plan stuck, since I'd have the new 8GB VRAM GPU already, so this take all this as specific to my hardware configuration case.

 

----

 

Okay now I used the Windows ADK 8.1 which has the Windows Performance thing that records ETL files.

 

The version of WPT is 6.3.9600.16384

 

 

Initial Report & File I/O rate (big 1440p image)

 

fX0tdLA.png

 

 

Ejection Details

 

rskQdhU.png

 

 

 

Disk Utilization

 

b2jTf6M.png

 

 

RAM consumption

 

I806VBO.png

 

 

EDIT: Yes I made a bit of fun with this case when it comes to the pilot eject area, I can't recreate the eject loading in other 3 more cases I did - I'll try some more next time.

 

 

And then I made another video: (tried to recreate the similar scenario as the WPT trace scenario)

 

 

 

-------

 

So the question is now, would loading all those textures to enable smooth views in the whole map amount to a ton of more required , considering system RAM isn't being used much, it doesn't mean everything on the map has to fit into VRAM, the primary point I want to make is that if you just load everything that the map needs into RAM in the loading screen and get the HDD storage out of the equation completely, and only the VRAM and RAM swapping memory it would be faster and wouldn't make these several second freezes and stutters, but correct me if I'm wrong.

 

And secondairly, I think it's not that hard for such a feature to be implemented, practicality of it may be another thing however doesn't matter, my next PC will have 32GB of RAM minimum, that's a done deal, but an optional setting would be most fair, I agree not everyone would want to use it all the time, especially 8GB users who don't like to close down and like to leave other stuff open in the background, +10 browser tabs, etc. Sometime's I'm in the middle of something and have 30 tabs open and don't want to close it all down.

 

An option in graphics menu then - "Max Out System RAM", or "Force Preload All Textures" - Tada! :punk:


Edited by Worrazen

Modules: A-10C I/II, F/A-18C, Mig-21Bis, M-2000C, AJS-37, Spitfire LF Mk. IX, P-47, FC3, SC, CA, WW2AP, CE2. Terrains: NTTR, Normandy, Persian Gulf, Syria

 

Link to comment
Share on other sites

Well oops ehm ... I see that "preload radius" slider in graphics options now, hmm, :doh:

 

I'll see how much it has to do with it ...

 

 

EDIT:

 

So I think the 3 reasonable areas that should be pre-loaded into RAM or VRAM and read from RAM or VRAM is ejection, crash, and respawn.

 

Now that I have NTTR, i'll see how this is true for that map.

 

I'll be much easier testing this once merge is complete, it may then be different for each terrain map.


Edited by Worrazen

Modules: A-10C I/II, F/A-18C, Mig-21Bis, M-2000C, AJS-37, Spitfire LF Mk. IX, P-47, FC3, SC, CA, WW2AP, CE2. Terrains: NTTR, Normandy, Persian Gulf, Syria

 

Link to comment
Share on other sites

I think I nailed it here with this summarization, it could be anything at this point, so I'm not making any assumptions, rather a list of possibilities.

 

I've checked Evict Allocations in the GPUView to see exactly what's going on with VRAM being too full and having to swap to RAM.

 

These are all left open questions at least for me now, I'll test more on NTTR 2.0 and 2.5 ofcourse, by then I should have the new GPU without this low VRAM issue getting in the way of these tests.

 

Unless someone with higher HW chimes in before that.

 

oOvIZBB.png

 

 

 

Not so fast, this alone doesn't confirm anything, when game needs to display requested scene it wants to put it into VRAM, since VRAM is full,

the evict allocation event happens, so:

 

A: is the required data already in RAM but because of not enough VRAM, is for some reason discarded and has to be reloaded from HDD ?

B: is the data required never loaded from HDD just because VRAM is full mid-mission load procedure

(eg. game doesn't fallback to putting it into RAM instead ?)

C: all the data is loaded successfully and fallenback to RAM when it doesn't fit into VRAM (swapped), but due to a buggy dynamic resource loader it for some reason:

A: either gets inconsistenly (randomly) unloaded from RAM (so sometimes ejections and ground crash impacts are smoother)

B: looks into HDD without looking into RAM, due to a bug, even tho the data needed is present on RAM, and gets overwritten

 

 

My original opinion was and is that the stuttering ingame (temporary freezes, affecting GPU activity) is caused by the delay required to seek and load data from HDD. I do not believe that the Allocation Evicts ( RAM & VRAM swap) are the source behind such big -

I believe the user would only experience something similar to microstuttering, and not heavy stuttering such as this with huge gaps.

 

However it may be the case that by complicated chain of events the low VRAM may be causing this indirectly, because the game doesn't fallback those resources onto the RAM, or something similarly, the dynamic resource loader in DCS manages these critical resources as "far away" and unloads them, I believe this is a mistake, these resources local to player should be always max priority.

 

I agree for the far out terrain it's not designed to be loaded into RAM all the time so that is NOT a bug, that's configured by options "Preload Radius" and maybe to some extent "Visibility Range".

 

However, the player aircraft resources including all death and damage stuff, explosions, ground impact is problematic, pilot model resources required for smooth ejection, should be always loaded in RAM whether or not they fit into VRAM, and should be ignored by dynamic resource loader too keep them from unloading.

 

 

Full Image:

Kdsw0Th.png

 

 

**************************

-------------------------------------

UPDATE: Yes, 8GB VRAM Fixed a lot, most of this issue is obsolete now and not valid, the remaining valid issues were carried over to the new thread.


Edited by Worrazen

Modules: A-10C I/II, F/A-18C, Mig-21Bis, M-2000C, AJS-37, Spitfire LF Mk. IX, P-47, FC3, SC, CA, WW2AP, CE2. Terrains: NTTR, Normandy, Persian Gulf, Syria

 

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...