How It Works - LordBlacksun/x3d-ccd-optimizer GitHub Wiki
How It Works
This page explains the technical background in plain terms. You don't need to understand any of this to use the app -- but if you're curious about why it exists and what it does under the hood, read on.
What is a CCD?
CCD stands for Core Complex Die. It's a physical chiplet on your processor containing CPU cores and L3 cache. AMD's high-end Ryzen processors use two CCDs to reach 16 cores:
- CCD0: Cores 0-15 (8 cores, 16 threads)
- CCD1: Cores 16-31 (8 cores, 16 threads)
Each CCD has its own L3 cache. Cores within the same CCD share cache and communicate quickly. Cores on different CCDs must communicate through the slower Infinity Fabric interconnect.
What is V-Cache?
V-Cache (3D Vertical Cache) is AMD's technology for stacking extra L3 cache on top of a CCD. On a 7950X3D:
- CCD0: 96 MB of L3 cache (32 MB base + 64 MB V-Cache stacked on top)
- CCD1: 32 MB of L3 cache (standard)
Games benefit enormously from large L3 caches because they constantly access the same data -- textures, game state, physics objects. More cache means fewer slow trips to RAM.
The Windows Scheduling Problem
Windows has some CCD awareness through CPPC (Collaborative Processor Performance Control) and AMD's V-Cache driver hints. However, the scheduler's decisions are implicit and not always optimal for gaming. In practice, game threads can still land on CCD1, and background apps can still occupy CCD0, competing for V-Cache resources. Users have no visibility into these scheduling decisions and no way to override them without third-party tools.
The result:
- Your game might place threads on CCD1 (missing out on V-Cache)
- Background apps like Discord and Chrome might land on CCD0 (polluting the V-Cache with non-game data)
- Threads bounce between CCDs, crossing the slow Infinity Fabric unnecessarily
AMD and Microsoft have taken steps to address this:
- Linux: AMD shipped a kernel-level patch that makes the scheduler fully CCD-aware. This is the most complete solution.
- Windows -- CPPC hints: Windows 11 uses Collaborative Processor Performance Control to receive hints about preferred cores from the processor. This helps but operates invisibly and inconsistently.
- Windows -- V-Cache driver: AMD's
amd3dvcachedriver exposes a registry-based CCD preference. This is a step in the right direction but is underdocumented, implicit, and doesn't give users visibility into what's happening. - Windows -- no user-facing control: None of the Windows-side solutions let you see where your game is actually running, or explicitly decide which processes go where.
X3D CCD Optimizer fills the control and visibility gap. It doesn't replace AMD's scheduling improvements -- it gives you a transparent layer on top of them, letting you see exactly what's happening across your CCDs and make explicit decisions when the implicit solutions aren't enough.
What This App Does
X3D CCD Optimizer solves this by directly managing process affinity on dual-CCD AMD Ryzen systems:
-
Detects your topology: Reads your processor's CCD layout, identifies which CCD has V-Cache (if applicable), and maps core numbers to CCDs.
-
Detects games: Uses a three-tier detection pipeline: manual rules (highest priority), library scanning of installed Steam/Epic/GOG games, and GPU usage heuristics for anything not recognized.
-
Pins games to V-Cache: Sets the game process's CPU affinity mask so it can only run on CCD0 cores. The game's threads stay on V-Cache where they perform best.
-
Migrates background apps: Sets background processes' affinity masks to CCD1 cores only. This clears CCD0 for the game and prevents cache pollution.
The app offers two optimization strategies: Affinity Pinning (directly sets CPU affinity masks for guaranteed CCD isolation) and Driver Preference (sets AMD's V-Cache driver registry key to prefer one CCD, working with the scheduler rather than overriding it). Both strategies migrate background apps. See AMD V-Cache Driver Preference for details.
-
Continuously monitors: Polling runs at 4 seconds when idle, switching to 2 seconds when a game is detected (active mode). Re-migration of newly launched processes happens within 5 seconds. Open Chrome mid-game? Caught and moved to CCD1 within seconds.
-
Restores on exit: When you switch back to Monitor mode or close the app, all affinity masks are restored to their original values. No permanent changes.
Game Detection Pipeline
The app uses a three-tier detection pipeline, evaluated in priority order:
- Manual rules (Settings --> Process Rules) -- highest priority, always wins
- Library scan -- automatically scans installed games from Steam (ACF manifest files), Epic Games Store (JSON manifests), and GOG Galaxy (SQLite database + registry hybrid). Scanned results are stored in a local LiteDB database (
user_games.db). - GPU heuristic -- monitors per-process GPU 3D engine utilization via WMI. Requires the process to be in the foreground and exceed the GPU threshold for the configured detection delay.
Detection source is shown in the activity log: [manual], [library], [auto-detected, GPU: XX%].
Library Scanners
The app includes three library scanners that run on first launch and can be triggered manually from Settings --> Detection:
- Steam: Reads
.acfmanifest files from each Steam library folder to identify installed games and their executables. - Epic Games Store: Parses
.itemJSON manifest files from Epic's local data directory. - GOG Galaxy: Uses a hybrid approach -- reads GOG Galaxy's SQLite database for installed games and cross-references with Windows registry entries for executable paths.
CCD1 is Not a Slow Core
A common misconception: CCD1 is not like an Intel E-core. It uses the same architecture running at the same clock speeds as CCD0. It just has less L3 cache (32 MB vs 96 MB on X3D chips). For background apps like Discord, Chrome, and Spotify, the cache difference is irrelevant. These apps are not cache-sensitive.
The only workloads that notice the cache difference are games and certain professional applications with large working sets.
CPU Affinity
CPU affinity is a Windows feature that restricts which cores a process can use. Every process has an affinity mask -- a bitmask where each bit represents one logical processor. By default, all bits are set (the process can use any core).
This app modifies that mask to limit processes to specific CCDs. The Windows API call is SetProcessAffinityMask() -- a standard, documented Win32 function that Process Lasso and many other tools use.
Setting affinity does not:
- Modify your processor or BIOS settings
- Change system-wide scheduling
- Affect other processes not managed by the app
- Persist after the app restores affinities
Performance Impact of the App Itself
The app's continuous monitoring loop is lightweight:
- Polls the process list at 4-second intervals when idle, 2-second intervals when a game is active
- Only reads process IDs and names -- no expensive operations
- Checks against in-memory HashSets (nanosecond lookups)
- The dashboard heatmap uses standard Windows performance counters
Typical CPU usage of the app itself: under 0.5%.