For a while now I have been getting fine performance in DCS. 2.5 has been good to me. However, since june or so, this has become brittle. For the first flight, its as sweet as it ever was. But if I re-fly (ctrl-R due to hot flaming death or otherwise), start another a mission or have another go after tweaking the mission a bit, it often becomes chugville after the second or third start.
Quitting out of the sim and re-starting it makes it run sweet again, for one or two flights.
This suggests to me the problem is not that my PC lacks the power to run the settings I have the sim on. If that were the case, the first flight would be as bad as the third.
I have looked at the sims memory usage, and it never fills out my 32gb. It should clear the video cards RAM, shouldn’t it? Might it be that this bit is broken a little?
Might there be some threads or processes that remain from the first flight and keep running and clogging up the pipes? Might there be a workaround to get things smooth again without having to reload the entire sim?
Help me Obi Wan KeForum, you are my only hope!
Have you tried hitting F11 a few times, then going back to the cockpit?
DCS never fills my RAM yet consistently crashes after it gets to 10 gigs (A couple of missions or restarts, or doing anything in multiplayer) Seems like its just how it is.
What card have you got and what temp is it at when it starts chugging? something could be throttling down after going over a temp threshold
Could be a bunch of things, but most likely to be GPU VRAM fragmentation or a memory leak. The bug (or algorithm that works well for when memory is empty but not so good when little space) could be on the DCS side, the DX side (unlikely) or the video driver side.
I remember something about DCS doing some changes around VRAM decompression or paging (in that for a large map it would move stuff in and out of memory more efficiently). That might have a bug that only becomes apparent after a while.
Really the only things you can do are:
See if you can gather diagnostics for VRAM usage (MSI Afterburner etc) in long missions/restarts and help ED with a bug report if it’s repeatable each time.
Update drivers (or go back drivers, as it’s a form of musical chairs for whatever works best).
@MigBuster’s idea is a good one, in that CPUs/GPUs do throttle down in heat, so that could be it as well.
While no so likely I remember there’s also the rebuilding of the … Those… The the the…that… Thing there. Shaders?
They do take a while to process, but I think in this case if it’s the second time around running the same mission then it shouldn’t be reprocessing them.
( heads-up: droning on a bit)
A shader is effectively a program that can run on a graphics card, and manipulate the frame/buffer very quickly. The can change the pure ‘bits’ (pixel shaders) but also perform operations on things like vertex’s, geometry and even general pure compute. It’s like the CPU only needs to give bare 3D coordinates (X,Y,Z sets) but then the GPU (via a shader) can then rasterize it (draw it as pixels on a flat 2D surface) in a really complex way, i.e. give it a lighting surface or shading that makes it look like a material (with a texture on it). The shaders are very efficient and can run in parallel as well.
Around about DX9 Microsoft (and OpenGL, and Nvidia with their own versions) came up with a way that different card manufactures could specify these shader programs in a common way. This ‘high level shading language’ (HLSL) are text files that the GPU (via the DX libraries) can read, compile and turn into running programs in the GPU. Because AMD and Nvidia (and even different models in the same family line) all compile these shaders differently (to make the most of their abilities) it’s like providing the ‘source code’ in a neutral way.
DCS has a bunch of these in the DCS/Bazar/shaders directory. The files ending in .hlsl or .fx contain the programs to do things like draw grass, give glass a nice effect, throw up particles when a bomb is dropped. You can actually open them in notepad and see the C-like code that gets run.
Because there is an initial performance hit to compile the shader files to run on the card you have, DX provides a binary format as a form of cache, so rather than file.hlsl → file.meta2/fxo → GPU the GPU can go straight to the binary cached form (for your card). DCS can’t ship these as they are driver and card dependent (a bit like you can provide the source code for a Linux or OSX program, but the .exe. wouldn’t work on both).
Tried this. It seemed to help. Perhaps flooding the video card ram defrags it?! weird
I also found a little video bios update that according to nvidea has something to do with the displayports. I ran it, because eh, cant get much worse.
Because as @komemiute indicates, murdering the metashaderizing fxo stuff (no, the pre-compiled shader programs) is good practice, I done that too (letting the program once again have a go at compiling non-borked shader programs).
I have been flying, tweaking the mish, flying again… with no stutters, no hiccups.
As I already suspected, heat is therefore not the issue, even tho it is for me
Thank you guys, y’all are awesome
@Admin ; we need a saluting dude icon such as this one, stolen from the worldofwarplanes forum.
Ok, but if they sue us for stealing the graphic we’ll split the lawyer bills.
For me, it seems to force a reload and can sometimes seem to have a flush effect. I tried it a few nights ago while playing multiplayer and getting stutters, it fixed the problem and I didn’t have to reload.