This is about avoiding the game locking onto, and hogging, primarily one core - which can potentially cause stuttering and fps drops as it butts into the single cores ceiling repeatedly.
If anything this method is simply about allowing the CPU’s that experience this issue to perform more as they were meant to to begin with. As such there won’t really be an fps increase as much as the game will simply utilize your CPU cores better.
to compound onto the points made by powbam and reply to klasperstanze -
i did not experience an FPS increase core switching, as my current hardware setup allows me to play Grim Dawn at a high frame rate to begin with. For more information, I cap the game in RTSS to 120 FPS, in the Nvidia control panel to 120 FPS, and I keep GSync enabled. I use in-game Vsync and application-controlled refresh rate at 120HZ.
The adjustments made to the CPU affinity are to, like powbam said, stop GD from eating up core 0. For my processor (9600k), I found that just switching off core 0 would simply cause GD to eat up core 1. It took a lot of trial and error to figure out the “recipe”. When GD would eat up a single core, I experienced frame drops and stuttering… my processor was “thinking” to hard on one core and would lock up the game. This method smooths out usage across all 6 of my cores and stuttering and frame drops are vastly reduced. Things like lootsplosions, encountering mobs, and the like, are all seamless more or less now for me.
This is my post, I lost access to that e-mail. A random logical core would get loaded to 60% minimum and then hit 100% at the most inopportune moments, causing lag.
I don’t know what changed since then, be it the game engine or the drivers or something else, but I started playing GD again and tried switching cores, and it worked. I set GD to launch using cores 2-11 in Process Lasso and then automatically switch to 0-11 after 5 seconds by means of a watchdog rule. Took this screenshot on Crucible wave 150-something, it wasn’t nearly one of the busiest waves but this looks pretty good:
Hi, thanks for this. I want to use this for TQAE. What does the beeping mean? It beeps when I activate it, then after a while again, and then again a bit after. Do have to leave this running after using it or can I close it after it does its thing?
Has anyone encountered an issue with Steam and finding the correct process to point the script to?
The only process I can find is called “Main Thread” which points to “Grim Dawn.exe”. When I manually turn on all CPU cores for this process it lowers FPS and smooths out the demand so I know it’s the correct process but I’m unable to grab a process ID.
Just tried your tool and while it helped free up CPU0, I can see in resource monitor it seems to be binding on CPU2 now- any ideas? Ryzen 2600 btw ( 6c / 12t )
EDIT: did a long trawl through this thread using the search and google, so going to post my solution here for anyone else out there similar. I downloaded Ryzen Master disable SMT (had to disable VBS for it, you can opt to not use the program- but then you will need to do it yourself) and then I ran the posted core switcher.
The results were positive, but not overwhelming. For some reason its shifted most of the load to CPU4 (5) but it’s no longer hitting max usage. Overall, the game runs much smoother, with little stutter.
For reference I have a 2600 w/ a RTX3070, M.2 SSD, G-Sync, Windows 11. I play the game with everything at maximum + forced 3d settings in nVidia CP, as well as GrimTex mod.
Thanks a ton for the tool, the Linux script worked like a charm after I refactored it to handle my 12 core system.
My “refactor” ended up turning into an almost 100% rewrite though, so I’m supplying my alternate version here in case anyone else is interested. Do what you will with it, my code is always released to the public domain.
The ways in which it differs are primarily:
Dynamically tailors itself to the number of cores present (i.e. it isn’t limited to 4,6,8/etc.)
Far less redundant code all around
Basic error checking (nothing fancy)
More explicit process discovery
Beeps removed (personal preference, easy enough to re-add)
Instructions are the same as the original Linux script: download, extract, set as executable, launch while the game is running. I recommend running the script in a terminal the first time just to be 100% sure it’s working.
Hi there, thanks for the awesome tool first. I encountered a weird problem which is that the windows tool for me will only allow core 1 and core 2 to work. I’m using Intel i9-13980HX which has 24 cores and 32 logical processers. Can anyone help me with that?
My rig is pretty decent (13700k and 4070TI), but kept getting some micro stutters here and there, so I figured, might as well give it a try and the difference is night and day, it has been smooth sailing ever since downloading the tool. Huge thank you for this.
I’ve returned to the game after years, and now i have this issue where the game won’t use multiple cores.
I’ve tried at least two community core-switches, the manual methods, editing the option file, and even downloaded process lasso.
Nothing. The game just uses a single core. And if i switch affinity manually, it just moves the load to the following aviable core, but no multi-thread usage at all.
IMO, core speed > core count. Grimdawn use an old engine that benefit higher clock speed more than multiple core. So you want newer cpu (better IPC and higher clock). i5 13600k is a sweet spot for 2k max setting. I’m using 17 14700k.
I have an I5 12600k with 32gb and a 3080 ti, running Steam and GD on a M.2 WD_BLACK 2TB SN850X.
I don’t really notice any hiccup or stuttering. I tested after coming across this thread, and I really can’t pin down any issues.
But. I did want to see how many cores GD was running on, and sure enough, when I looked at the Resource Monitor after playing for 10 to 15 seconds. CPU O was close to 100 percent.
So, I opened Task Manager and right clicked on Grimm Dawn and unchecked CPU 0. Then I went back in game for another 10 to 15 seconds, and then hopped out to look at the Resource Monitor, and sure enough, Grimm Dawn was now using multiple cores and none of them were coming close to 100 percent.
Just posting this for anyone with an I5 12600K that may have some issues. I’m also playing at 1440p with no issues that I can perceive.
Neither Core Switcher works for me. I hit Ctrl + Alt + o and it doesn’t turn off any cores or restart them for me. I can hit Ctrl + Alt + I, and it shows me my CPU information, so it works, but it doesn’t shut down any cores while I’m playing Grimm Dawn.
If I do it manually from Task Manager it works perfectly. I tried with Administrator and it didn’t work that way either.
I can tell that I am using Ryzen 7800x3d + rx7900xtx and performance isn’t that super super perfect. I tried many different configurations and still no 100% reliable setup to run GD in 165fps 100% time on maks settings for me. I am testing Vulcan now and it seems better. Idk maybe there’s something wrong with my GPU? Will be testing further. Still lock on 100fps is not bad at all, quiet and smooth gameplay. Still was hoping getting my monitor refresh rate easily. And it’s still not the case for me… Idk why…
Hello, I am currently battling the game to utilize more than one core on my i7-10700KF, too. I tried this method since the game keeps clogging up Core 0 until it reaches 100% and then drops alot of FPS (happens with too many enemies on screen), but all it does is making it clog up another single core instead of spreading out the usage.
I was really sad about this because this seemed like the perfect solution
I also tried leaving Core 0 off completely or turning off all non-physical cores, but nothing changes. Compltely out of ideas, does anyone have some shady CPU wizardy ideas left?
First I wanted to thank @Zantai for answering my question to clarify the core situation, due to a comment about how GD isn’t a single-core game. That thread on the steam community boards was horribly toxic, so I wasn’t sure if there’d be a response.
To sum it up, Crate devs have offloaded some work to other cores, but because the engine is ancient and built in a time before multi-cores were common, we can still see Core 0 max out in intense situations.
I’ve tested this, and it seems like Core 0 at 100% doesn’t necessarily mean you’ll have performance drops. Mine sits at 100% constantly while the game is open, but it still runs smoothly until I hit heavy environmental effects or screens full of actors (monsters, pets, etc).
So, in Titan Quest, the trick of disabling and re-enabling Core 0 does have a noticeable effect on performance for most people who’ve tried it. The more testing I’m doing with GD, however, the less it seems like doing this has a strong impact, at least for me. Maybe a few FPS at most in graphically intense situations, but not the same results as TQ but any means.
This might be due to hardware. This computer is running an i7-13700K at 3.40 GHz. I’ve gone through several systems since GD was in early access, and I honestly can’t remember what the performance was like back in the day, so I figure I might as well ask here.
There’s been 4 and a half years since this tool was released and brought the issue to the GD community’s attention.
Does anyone notice a difference in GD with the Core 0 cycling trick these days? On high end hardware versus older hardware?
7700K, 4 Core W/HT 4.8. 3200, xmp. 6700xt. Red Devil, 1440p, Adrenaline frame limiter to 140 fps, Freesync no Vsync. Windows 10.
I usually use Process Lasso Pro and CorePark, using the Bitsum Highest performance power setting and Changing the GD exe to High Priority.
I have slowdowns in Asterkarn and The “secret” new area in ashes expansion. Blame it on Z270 IPC. I’ll give it a shot.
After 15 mins of testing alongside my usual setup it seems it just offloads from core 0 to core 2. While in Asterkarn. No noticeable performance 1% lows
Without PL and CP, Core switcher on its own, I saw a small shift initially to 4 cores with core 4 being favored, then after 5 more minutes while heading to Ashes secret area it shifted 90% of the load to core 4 and stayed there. Performance hit was noticeable with slowdown and stutters.
Process Lasso and core park seem to work best for me with the frame limiter. Overall a much more smooth exp.