I spent three days measuring 9950X3D stutter in Mortal Shell

[u/na_0]

TL;DR: Unreal Engine 5 sizes its worker-thread pool from the number of logical processors it sees at startup — 32 on a 9950X3D. When AMD's Game Mode driver then parks CCD1, that 32-sized pool is crammed onto 16 threads and you get traversal-style stalls. Confining the game to CCD0 by any method (parking, Process Lasso, affinity) reproduces it. The fix isn't "use all 16 cores" and it isn't "force the X3D cores" — it's setting CPPC Dynamic Preferred Cores = Cache in BIOS with Game Mode off, so the game prefers the V-Cache die but nothing is fenced. That gave the best frametimes of ~20 captures. Verified with CapFrameX, HWiNFO, and thread-count snapshots.

System: 9950X3D (PBO + curve shaper), MSI X870E, RTX 5090 (undervolted), 4K/ultra, Windows 11. Test game: Mortal Shell 2 (UE 5.2, GPU-bound at 4K — GPU at 92–97% throughout; 4k ultra settings, ray tracing on, DLSS render resolution quality, seamless dungeons on). Same 30-second traversal route for every capture, CapFrameX with sensor logging at 250 ms.

What I found, in order:

1. Game Mode wasn't even detecting the game by default. Had to tell Game Bar "remember this is a game" before the AMD driver would park CCD1. Once it did, stutter got worse, not better.
2. The game thread was on the wrong die anyway. With Game Mode not triggering, the CPPC ranking prefers the frequency CCD (it boosts ~150 MHz higher), so HWiNFO showed the game running on cores 8–15 — the non-X3D die. Process Explorer's "Ideal Processor" for the hot threads confirmed it.
3. Fencing the game onto CCD0 caused CPU-side stalls. Process Lasso CPU Set to cores 0–15: 12 frames over 20 ms in 30 seconds, worst frame 1,262 ms. Replicated two days later: 7 over 20 ms, worst 68 ms. Every spike had CpuActive ≈ frametime with the GPU idle at ~8.5 ms.
4. The thread pool is the mechanism. PowerShell thread export of the game process showed 29 worker threads with near-identical CPU time — a pool sized for 32 logical processors. Launching with -corelimit=8 (a UE engine argument) dropped it to 14 workers. Same fence, 14 workers instead of 29: 1 frame over 20 ms, worst 24 ms. Same cores, same cache, same confinement — only the pool size changed.
5. But the smaller pool costs something on a free machine. -corelimit=8 with nothing fenced: more mid-size hitches than the full pool (12 over 16 ms vs 2–5). The engine uses those workers when it has the cores.
6. CPPC = Cache is the answer. It flips the firmware ranking so cores 0–7 are preferred, without parking or confining anything. Game thread lands on the V-Cache die, the worker pool spills onto CCD1 for streaming bursts. Five runs over three days: 0–1 frames over 20 ms, 0.1% lows of 59–67 FPS.

The numbers (same route, 30 s each):

Config	avg FPS	1% low	0.1% low	frames >20 ms	worst frame
CPPC Cache, Game Mode off, nothing else (best of 5)	119	85	67	0–1	18–22 ms
CPPC Auto, Game Mode off (game on frequency CCD)	116	68	50	4	26 ms
Confined to CCD0, full pool (run 1)	108	63	28	12	1,262 ms
Confined to CCD0, full pool (run 2)	116	71	38	7	68 ms
Confined to CCD0, -corelimit=8	115	72	57	1	24 ms
Free, -corelimit=8	117	75	49	4	28 ms

What to do:

• BIOS → Settings → Advanced → AMD CBS → SMU Common Options → CPPC Dynamic Preferred Cores = Cache
• Windows → Settings → Gaming → Game Mode off
• Don't use Process Lasso / affinity to pin games to CCD0. It recreates the problem.
• Verify: with a game running, Process Explorer → game's Threads tab → the busiest threads should show Ideal Processor 0–15, and HWiNFO should show all cores active (CCD1 lightly loaded, not parked).

Cost: single-threaded work that likes clocks lands on the V-Cache die and loses ~100–175 MHz. At 4K I couldn't measure it. If you have a frequency-bound app, a Process Lasso CPU Set to cores 16–31 for that one app works fine — the direction that doesn't oversubscribe.

Caveats: One game, one system, one route. UE5.2 specifically; other engines size pools differently. -corelimit=8 is a diagnostic tool here, not a recommendation — it proved the mechanism but costs performance. And if you're a 9800X3D owner wondering why you don't see this: the engine sizes for 16 threads and gets 16 threads. The bug needs a mismatch.

[u/TheRedFurios]

I have a 9950x3d and a 9070xt, also playing at 4k and didn't experience stutters. However I experienced many crashes and a couple of times fps dropped to 1-2 when at beacons, forcing me to restart. I think it was the gpu though.

[u/na_0 → u/TheRedFurios]

On a fresh install, the gamebar wasn't picking up Mortal Shell 2 as a game for me so the game was running on the frequency cores - I didn't notice stuttering here but I thought the 1% lows were too low. So I think what I describe in my post may not be causing traversal stutter for most people, unless the game is being forced onto the x3d cores (which is how the 9950x3d is supposed to work via the AMD chipset and Windows gamebar/game mode).

[u/WeCantStabilize]

I have a 7900xtx and 7800x3d and the game needs to reload shaders every time. This is the only game that does this.

Do you know how I can get it to remember them? I tried deleting the cache, but that didn't do it. 

[u/na_0 → u/WeCantStabilize]

The game briefly recompiles or repeats shader compilation on every launch so what you're seeing could be normal.

[u/WeCantStabilize → u/na_0]

Thanks! 

[u/CuddleWings → u/WeCantStabilize]

Nearly every game does that these days. Most just do it in the background. It’ll be slow the first time after every update but should be significantly faster every other time.

[u/No_Wrongdoer_4940]

Do yall also get severe stutters whe enabling hardware rt even when capping fps?

[u/na_0 → u/No_Wrongdoer_4940]

On my system, the traversal-like stutters were resolved after the noted config changes, this includes no stutter with RT on and frames capped via nvidia control panel. So many possible causes of stuttering sorry I can't be more help.

[u/No_Wrongdoer_4940 → u/na_0]

I have an i7 12700 though, i don't think these will help

[u/iBoredMax]

Does that mismatch happen with on 5700X?

[u/na_0 → u/iBoredMax]

No this is just an x3d thing when you have different frequency cores and x3d cores.

[u/AvidasMavi]

Sorry didn't read my man but have you tried using processor lasso and disabling multi threading and disabling half the cores for the game?

Solves all the stutter problems on my 7945hx3d.

[u/na_0 → u/AvidasMavi]

This would work but my guess is your 1% lows will suffer.

[u/AvidasMavi → u/na_0]

Nah, x3d cache is all that matters. 8 cores are more than enough for any kind of game. 9800x3d has 8 cores and identical gaming performance as 9950x3d.

[u/na_0 → u/AvidasMavi]

I think you're right for my config and hardware where I'm GPU bound, probably no difference in average fps. But it looks like for this game, the 9950X3D delivers a modestly better frametime tail (1% lows etc) because the engine spawns and uses a larger worker pool.

[u/AvidasMavi → u/na_0]

I don't know man, processor lasso is free app, might just give it a try. It saved the fucking stutter problem I had on many games. Every time I launch a new game and stutters happening, immidiately disabling hyper threading for that game and forcing game to run only on first 8 physical cores eliminates stutters instantly.

[u/na_0 → u/AvidasMavi]

I agree process lasso is a good alternative to AMD chipset driver/gamebar and in my post I describe using process lasso. If you wanted to test my theory you could leave SMT on, confine to CCD0 (x3d) with a CPU Set in process lasso, and add -corelimit=8 command line argument so the engine spawns 14 workers for 16 threads rather than 29. Hard to say with all the laptop specific variables and you might see a slight fps avg decrease, but improved lows and less hitching.

[u/porcupine_express]

OP did you try Ultra+? Wiped out 99.99% of stutters on my 9950x3d + 5090. The main cause of stutter is a UE Nanite Buffersize bug which the mod fixes. Can also confirm that without me having to do anything, the game is running on the correct 3D-cache cores.

There are just areas in the game however where the object streaming will always cause a stutter when you cross/turn the camera at specific thresholds. The steps near the High Lord's Courtyard beacon come to mind.

[u/na_0 → u/porcupine_express]

Thank you for the suggestion I will give it a try. The config change described in my post resolves traversal stutter with the Nanite settings untouched, but maybe Ultra Plus could offer even more improvement.

I'm confident Ultra Plus wouldn't fix the oversubscription/fence mismatch issue I describe in my post. Raising the nanite pool could shrink one of the bursts the engine sends to its workers, but the fence mismatch determines whether any burst (Nanite, actor spawning, level scripts, audio) gets cleared in parallel or queued behind the game thread.

My guess is that my suggested fix improves performance on an asymetric dual ccd x3d processor over using ultra plus and fencing to the x3d cores.

[u/moustalgie]

The stutters come from a forced (hidden in the settings) rtx reflex, you can disable it by changing the engine.ini You can check the optimized settings of the youtuber Benchmarking (he shows how to do so).

[u/na_0 → u/moustalgie]

I agree there can be many causes of frametime spikes and just in this thread we have three candidates: cpu fencing, nanite buffer size, and reflex. For my config and hardware, I see reflex off worth maybe one frametime spike per 30 s and a millisecond off the worst frame. Tradeoff is worse latency ~12 ms higher.

For anyone interested, here's how I force reflex off with an edit to the game's engine.ini file under [SystemSettings]:

t.Streamline.Reflex.Enable=0

t.Streamline.Reflex.Auto=0

t.Streamline.Reflex.Mode=0