安装 Steam
登录
|
语言
繁體中文（繁体中文）
日本語（日语）
한국어（韩语）
ไทย（泰语）
български（保加利亚语）
Čeština（捷克语）
Dansk（丹麦语）
Deutsch（德语）
English（英语）
Español-España（西班牙语 - 西班牙）
Español - Latinoamérica（西班牙语 - 拉丁美洲）
Ελληνικά（希腊语）
Français（法语）
Italiano（意大利语）
Bahasa Indonesia（印度尼西亚语）
Magyar（匈牙利语）
Nederlands（荷兰语）
Norsk（挪威语）
Polski（波兰语）
Português（葡萄牙语 - 葡萄牙）
Português-Brasil（葡萄牙语 - 巴西）
Română（罗马尼亚语）
Русский（俄语）
Suomi（芬兰语）
Svenska（瑞典语）
Türkçe（土耳其语）
Tiếng Việt（越南语）
Українська（乌克兰语）
报告翻译问题
讨论规则及指引
举报此帖
So, am I understanding you correctly that you have not tried the processor scheduling stutter fix because it makes no sense?
Since my months old entries in this thread, I find that much of what I said is now out of date. I say that only people with i5's have reported that the stutter fix works for them, However more recently, there have also been a number of people with i7's reporting that the stutter fix has worked for them. The OP in the thread below has an i7-7700 (4 cores/8 threads) for example. Also, in post #13, I have included my CPU/GPU usage graphs with processor scheduling fix off/on for my system (i5-2400, GTX 1060 6 GB, 16 GB RAM).
https://steamcommunity.com/app/275850/discussions/1/3430075523236502661/
I'm not sure what the system specs are of the OP of the following thread, but they say the stutter fix worked for them and they also say that the GOG version of NMS never had stutters. So, maybe the GOG version might work better for you too.
https://steamcommunity.com/app/275850/discussions/0/3430075523247103249/
Some say to turn off multiplayer and/or turn off Steam overlay to reduce stutters, I always have MP off and NMS stutters pretty bad without the processor scheduling stutter fix. I haven't tried turning off Steam overlay, because the stutter fix does a good job for me and I like having Steam overlay on.
On my old system (i5-3350P, 1050ti, 8GB RAM, Win8.1), if I started NMS after turning the computer on (from total power off), it'd run at something like 5 frames per minute. I couldn't even get past the SP/MP select screen.
If I then rebooted the computer and started NMS, it'd run fine. It was completely repeatable, and all other games ran fine without me having to reboot.
This is just a guess, but it was like NMS, for some reason, chose to use the i5 internal graphics instead of my graphics card, BUT the i5-3350P didn't have internal graphics, so...
And I haven't a clue why it could then figure out how to choose the right graphics after a reboot.
You should test 1080P resolution naitvely without dlss. See if that improves.
AMD Ryzen 9 5900X 12-Core Processo, 3.70 GHz
32.0 GB
2TB SSD
Win11 Home 64 bit
My Settings :
https://prnt.sc/7eWqhvEkbtwQ
https://prnt.sc/cIARYk8m4cGv
Geforce Overlay disabled
Only Discord /Steam running if I play NMS
Sometimes it helps to delete TKGRAPHICSSETTINGS.MXML and let it written again at a new start of NMS
Nvidia Control Panel :
http://prntscr.com/17oiiui
make sure your GPU is selected
And did add NMS in Windows Graphics Settings http://prntscr.com/102aa7b
Thanks for the additional information. Pretty wild to hear someone say that a different platform of the game works better.
Tonight I performed a lot of testing in 15 minute groups and concluded that the results are so inconsistent after loading over a dozen tests (for about 4 hours real time) the stuttering just went away on its own and then returned again. Made it hard to test isolated settings in a group and try to conclude anything. This leads me to think along the lines of an issue with the shader cache. The stuttering is exactly similar to other games when they are building a shader cache for the first time. (usually on first run or after updating nvidia driver) Otherwise solid 60 fps framerates sitting at the nvidia control panel frame cap. (anyway those are just my thoughts, not saying they are any more valid or important than anyone else's findings)
It bothers me to see the nvidia shader cache folders empty. The shader cache for NMS appears to be located in the steam shader cache folder instead. The NMS dir also has its own shader cache folder which is empty, maybe the other platform versions use that one? I wonder what the retention is? The nvidia driver has a cache size setting. What is the NMS cache size limit? Mine is about 400 MB right now.
The processor scheduling setting did not change anything. I have a stack of 15 minute screenshots of the performance monitor running a handful of counters against CPU, GPU, disk loads, RAM usage, etc. The charts are identical as they can be no matter what the scheduling is set to. (and during testing stutters either way)
CPU loads to about 50% averaged. 1x core goes to 95%, 1x core goes to about 75%, then the remaining 6x cores sit at 40% with spikes. CPU across the board in a 15 minute period shows around 40-50% with heartbeat spikes to 70-90% very frequently. Outside of the game nothing running (except the monitoring apps) and I didn't see anything blip on the monitoring workflow to cause additional stress on resources. Something I noted was that CPU sits at about 20% on barren planets and easily jumps to 30% on planets with trees and AI life etc. (makes sense)
Left the barren planet to load the GPU more and observed it to stay around 40-60% usage throughout the 15 min period. No GPU spikes occurred. When flying in space the loads drop notably across the board.
Crashing into the ground in a starship on a planet causes a very reproducible CPU spike to 100%. Not sure the cause, the hud flashes red from the crash and a sound effect plays, other than that the camera is basically looking at the ground. But the resource load on that event is notable and seemed easy to reproduce.
It took awhile tonight to setup a decent workflow to watch and capture data at the same time. Captured good data in the beginning but running the game in full screen I couldn't correlate the data to stuttering so it appeared useless without that knowledge. A CPU spike did not necessary mean stutter. In order to watch all of the performance counters and see the game stutter at the same time I put it in a bordered window at 1080 with no DLSS. Changed the preset to ULTRA to assure hardcore stuttering could be seen from the tiny 1080 window against a 4k backdrop full of monitoring tools. GPU loaded to about 6.4-6.6 GB VRAM usage. Memory loaded to about 9GB with 23GB free, about 3GB of that 9GB used from a boot-to-desktop OS idle. Both M2 drives sit idle with almost no notable loads at a 1 second resolution. NIC has a slight heartbeat unbothered by stutters or other resource usage. Really the important monitoring factors seemed to be the CPU and GPU as one might expect.
There are a couple of notes I made about testing a few other areas. Maybe I can get to those tomorrow. (disable steam overlay, maybe try steam in offline mode, that kind of stuff)
Hi.
Thanks a lot for doing so much research and benchmarks. You did a hell of a lot more than I did.
While I haven't been playing the game ever since I contributed to this thread, I did try the new updates.
I was hoping one of them would silently fix the issue but for me personally, it got a LOT worse.
I had a benchmarking planet where I did all the tests I reported and I tried it again after the updates and it was so much worse. I felt like I was clicking through a powerpoint presentation.
I agree with your points. The issue is extremely inconsistent and there seems to be very little correlation between the performance and the hardware the people are reporting.
I am waiting for the new ZEN 4 cpus and intel CPUs and I will make a new build with which I will test this again and report here...
Hey Teo nice to see you again. Your previous advice on the planet details is spot on.
Continued testing tonight with the newly established monitoring workflow. Found out some interesting things and have a bit of a workaround (I believe anyway) for major stuttering. Spoiler alert, disable all shader caching. Call this a workaround because I think the actual feature of shader caching as implemented in this platform of the game is doing more harm than good.
Tonight I parked right next to an outpost which seems to be a big offender and is fast tracking me to stutter-ville. This helps reduce time trying to re-establish the issue. I've also reduced most of the graphical options while flying around and this made no changes to the stuttering but did release about 500mb of VRAM. (dropping usage from 6.6 to 6.1 GB) The game did not tell me to restart while doing that until I reached the tesselation option, at which point I restarted. After a reboot the VRAM would be quite a bit less and can easily rest around 3-4 GB on these lower settings. This doesn't solve the stuttering and really just ends up leaving a half allocated bank of GPU VRAM. Can be done but it would be like using half of the hardware resources just for giggles.
With that said I do believe that ULTRA settings are too much for an 8 GB VRAM GPU no matter how good it is. This is just a simple math problem so the game's note about 8+ GB next to ULTRA textures is accurate. At one point something happened and I saw usage pop out from 6.6 GB where it was stuck for awhile to 7.4 GB which was either luck it didn't crash out to 8 GB or perhaps there is a limit within NMS to avoid that. I know how to crash a GPU with a too-big CAD render but I digress. At 7.4 GB the stuttering was pretty intense so I thought immediately mistakes were made on my part. Not so fast though, the same stuttering is heavy at 6 GB VRAM and lower so the issue is not solely linked to an overuse of VRAM.
Here is a quick overview of the test areas tonight:
* still using a bordered window at 1080 resolution so monitoring tools are visible and on the fly investigations can be made
* dropped all settings to lowest (STANDARD) except for planet and base at ULTRA (still stuttering with CPU spikes)
* unplugged ethernet cable during session with no change (after observing NMS.exe TCP/UDP traffic) the network traffic stopped (of course) but no changes to stuttering
* disabled steam overlay
* tried to close steam mid session but that just resulted in steam closing NMS before closing itself
* disabled defender core isolation (specifically HVCI) (not recommended due to security concerns)
* updated C++ runtime for year 2017 as NMS.exe seemed to be loading that DLL and my version of 2017 runtime was out of date
* added exclusions to defender for three areas observed from in depth monitoring on NMS.exe:
-> NMS folder
-> NMS save game folder
-> NMS shader cache folder (it uses the aforementioned steam cache folder on steam platform -> steamapps > shadercache > 275850) (fozpipelines and nvidiav1 dirs)
* swapped from using USB headset to enabled realtek onboard sound in BIOS and plugged in analog headset to see if any load reductions on CPU (no changes)
So when looking at the NMS.exe the majority of time it is reading pak files in GAMEDATA PCBANKS dirs which makes sense. I thought maybe a stretch that the ms defender was impacting the game for some reason. Went wild from there and added all kinds of exclusions which did nothing to help.
Trying hard not to go down rabbit holes and only look at what is the problem that some players have but clearly not all the players. This is when it hit me about the USB headset I use and thought about that impact to the CPU. This lead me to trying the realtek onboard sound which I assumed is probably a majority of players since that is the defacto onboard audio chipset in recent years.
As I closed down the game to call it a night a number of new shader cache hits occurred in the monitors. These were coming from steam platform (where was not of particular focus for testing tonight) and writing files to areas including program files x86 > steam > userdata > userid > config > shaderhitcache. Folders like vulkanpipelinev6 and folders with guids in the name. Before wrapping, decided to test again and disable precache of shaders within the steam client settings, and then also for good measure disable shader cache from the nvidia control panel.
Found it interesting that the shader cache cannot be tuned per game. It only exists in the global settings. I'm still not sure if the nvidia control panel setting actually does anything regarding NMS shader cache since it does not appear to be using the nvidia dirs for that purpose. With both cache items disabled I hop back in and to my surprise, most of the stuttering was gone. Now not all of the stutters, but activity in the process monitors subsided where shader file reads / writes were concerned. The game played much smoother but will need more testing. Even if this worked it would be considered a workaround because turning off caching is not ideal. Caching is supposed to stop the stutters not cause worse stutters. If someone else can test disabling the shader caching it would be super helpful.
If anything I have a huge new found respect to the amount of tasks this computer can do at the same time. If anyone is interested in the tools I am using, a pair of process monitoring tools from sysinternals kit over at ms, Process Monitor and Process Explorer. Also using Task Manager to a lesser extent because the graphing is easy to throw on the screen edge and polling easy to adjust. Also using Performance Monitor to run counters when looking across a time frame. (those aforementioned 15 minute screenshots from last night) Good troubleshooting skills to have if in the tech field or thinking about entering. See how exe files interact with the system, with supporting dlls, with other platforms, file activity on the disk, process threads, etc.
use borderless for easy tabbing and game restoring in 5-10 sec to no stuttering
There is not much else I can think of testing. Covered all major areas I could possibly think of.
I'd still like to speak a little bit about shader caching, and that moving forward it would be nice if we could have some more options regarding this feature. Most importantly, I'd like to be able to choose which disk to locate the shader cache from both steam and the nvidia control panel. I have no idea what the steam "shaderhitcache" folder does in the steam program dir, anyone know?
See, shader caches as implemented can exist on the C disk by default, both through the nvidia CP storing them in the C > users > username > appdata folder and also in steam's use of the program files x86 steam dir. Both of these locations could potentially be located on a slower disk in a multiple disk system. IMO, shader cache for a game should exist either within the game dir itself, or be configurable so we can decide to locate that cache on our fastest disks.
As for the game, continued testing just confirms the random nature of stuttering and it seems once caught in that situation, perhaps reloading the game might have the best outcome. Also, after examining the default graphic settings file TKGRAPHICSSETTINGS I suspect things like massive motion blur and a very zoomed in field of vision are helping with any stuttering. I prefer a very high FOV and so it is typical for me to play at 100. The default is something like 75 which is very very zoomed in to me. Maybe this is allowing the camera to render much less objects within a scene.
For a number of hours now I have been testing the default graphics settings and again it seems like the performance is much better. In my system the game is loading to 1080 resolution and HIGH present by default. This is quite similar to my custom settings, except I max FOV to 100, disable motion blur, expand resolution to 4k then DLSS to 1080. I also turn vsync off and use the nvidia CP settings. The game has triple buffered vsync on by default. Maybe the triple buffering is also helping. I do not normally use triple buffering and prefer to save that VRAM for better graphic settings. Perhaps in this game those settings I have grown accustomed to are causing me frame rate stabilities.
If anyone has thoughts on FOV, triple buffering, shadercaches, I'd like to hear it. Is there anyone out there without issues that would like to share their settings? Don't need the file just a little information on what settings other folks change from the default. Thanks.
Generally speaking, this is awful advice. Windows is specifically designed to prioritize fullscreen applications i.e. you're letting unnecessary background tasks eat up your CPU cycles for literally no reason. Fullscreen mode has also been getting optimizations since Windows 10 to improve its multitasking efficiency, making alt-tabbing for instance much less painful than it used to be. Ignoring poorly designed game engines that (somehow) perform worse in fullscreen, there is no reason to be running borderless if performance is your primary concern.
The CPU usage spikes have made this game entirely unplayable. Constant micro freezing and stuttering, with fps drops down to mid-teens due to CPU usage spikes.
This is on a fresh install of the game, downloaded just today.
I have done all the old config file edits, none changed the performance. I tried turning all settings down to absolute lowest, no improvement. The recommended spec being an Intel i3 is a joke.
I do not alt tab, so that has no bearing on this.
What a joke.
Actually, they updated the requirements since I last checked some years ago, now a 3GB 1060 is the minimum requirement (which is odd considering they alternatively list an Intel UHD 630 as minimum, and even the slower 3GB 1060 is a hell of a lot faster than the 630) and I think they recommend a 1070.