Tirones en juegos con un Ryzen X3D de dos CCD: por qué pasan y cómo arreglarlo en Linux

Dos CCD y solo uno con caché

Los Ryzen de sobremesa y los HX de portátil se fabrican mediante chiplets: uno o dos bloques de núcleos, llamados CCD (Core Complex Die), y un chip independiente para las conexiones y la memoria, el I/O die. Cada CCD dispone de hasta ocho núcleos y de su propia caché L3 de 32 MB, la cual es compartida solo por esos núcleosref.

La 3D V-Cache añade 64 MB de caché apilada sobre un CCD, o debajo en el caso de la serie 9000. De este modo, ese CCD pasa a disponer de 96 MB de L3. En los modelos que tienen dos CCD, AMD solo apila caché en uno de ellos. El otro mantiene 32 MB, pero alcanza frecuencias más altas: solo el CCD sin caché llega al turbo máximo del chipref.

Un núcleo solo usa directamente la L3 de su propio CCD. Si necesita un dato que está en la caché del otro CCD, la petición viaja por el I/O die. En el Ryzen 9 9900X, ese viaje entre CCD tarda más o menos lo mismo que ir a la RAMref.

Qué modelos tienen dos CCD con caché distinta

Datos de la lista de procesadores Ryzenref, la ficha del 9850X3Dref y el anuncio del 9950X3D2ref.

• Un solo CCD. Todo el procesador comparte la misma L3 de 96 MB. No hay nada que elegir, y este artículo no aplica.
• Dos CCD, caché en uno. El caso de este artículo. En el 7900X3D y el 9900X3D, el CCD con caché tiene solo seis núcleos (doce hilos).
• Dos CCD con caché en los dos. El Ryzen 9 9950X3D2 salió el 22 de abril de 2026 y es el primero con 3D V-Cache en los dos chipletsref. No tiene un CCD «bueno» y otro «malo». El salto entre CCD sigue existiendo, pero es el mismo que en un Ryzen 9 normal.

Por qué aparecen los tirones

Quién decide qué núcleos usa un juego

El planificador del núcleo de Linux es el encargado de repartir las tareas entre los núcleos. Cuando hay núcleos libres, se basa en una clasificación proporcionada por el propio procesador mediante CPPC: cada núcleo recibe una nota y se priorizan aquellos con la puntuación más alta. El controlador amd-pstate es el responsable de transmitir dicha clasificación al planificador. Esta función se denomina preferred core, núcleo preferidoref.

En los X3D de dos CCD, el firmware puede ordenar esa clasificación de dos maneras. Para elegir entre ellas, Linux 6.13, publicado el 19 de enero de 2025, incorporó el controlador amd_x3d_vcacheref. Lo escribieron Basavaraj Natikar, Perry Yuan y Mario Limonciello, ingenieros de AMDref, y lleva el mismo nombre que el componente equivalente de Windows: AMD 3D V-Cache Performance Optimizer. Ofrece dos modosref:

• frequency: los núcleos del CCD más rápido, el que no tiene caché extra, van primero.
• cache: los núcleos del CCD con más L3 van primero.

El modo predeterminado de fábrica es frequencyref, algo que Phoronix confirmó en sus pruebas del 9950X3Dref. Esta es una buena elección para un compilador o cualquier programa que se beneficie de cada megahercio. Sin embargo, no lo es para muchos juegos: el juego comienza en el CCD con 32 MB de L3 y la caché que justifica la compra de un X3D se queda casi sin usar.

Es solo una preferencia

Ninguno de los dos modos aparta un CCD. Si el juego tiene más hilos que núcleos libres en el CCD preferido, el planificador utiliza también el otro. En el equipo del ejemplo, Counter-Strike 2 tenía 76 hilos en el CCD con caché y 41 en el otro, incluso con el modo cache activado. Para evitar que el juego salga del CCD con caché, hay que fijarlo a mano, como se explica más abajo.

Por qué cae el 1 % low y no tanto la media

La media de FPS contabiliza todos los fotogramas. El 1 % low, en cambio, se centra en el 1 % más lento, que es lo que se percibe como tirones. Un fotograma no se completa hasta que finaliza el hilo más lento del que depende. Basta con que ese hilo acabe de vez en cuando en el CCD equivocado para que ese fotograma tarde bastante más que el resto.

Hay dos efectos que se suman:

• Menos caché. Los juegos dependen mucho de la latencia de la caché y de la memoria. Cada vez que un dato no está en la L3, el núcleo espera a la RAMref. Un hilo en el CCD de 32 MB falla más que uno en el de 96 MB.
• Datos que cruzan de un CCD a otro. Si dos hilos que se pasan datos están en CCD distintos, cada intercambio cruza el I/O die. En un Ryzen 9 9900X, sin 3D V-Cache, repartir un juego entre los dos CCD rindió un 7 % menos que fijarlo a uno soloref.

En un X3D, el segundo efecto se suma a la diferencia de caché entre los dos CCD.

Lo que pasó en el equipo del ejemplo

Se utilizó un PC con Ryzen 9 7945HX3D, RTX 5090 y CachyOS, que alcanzó una media de unos 400 FPS en Counter-Strike 2. La mejora se notó al momento, sin reiniciar el equipo. Es una sola medida en un solo juego, no una prueba de laboratorio.

El modo cache no siempre es la mejor opción. En las pruebas de Phoronix con el 9900X3D, algunas tareas resultaron más rápidas en cache y otras en frequencyref. Por ello, es necesario hacer pruebas con los juegos propios y fijarse en el 1 % low, no solo en la media.

Cómo saber qué CCD tiene la caché

Estas cuatro comprobaciones no modifican ningún ajuste. Se realizan en una terminal, utilizando el usuario normal.

1. Qué núcleos comparten cada caché L3

Linux describe cada caché en /sys/devices/system/cpu, siendo index3 la correspondiente a la L3. Este bucle muestra cada L3 distinta, indicando su tamaño y los núcleos que la comparten:

for d in /sys/devices/system/cpu/cpu*/cache/index3; do
  echo "$(cat $d/size) $(cat $d/shared_cpu_list)"
done | sort -u

Resultado en el equipo del ejemplo:

32768K 8-15,24-31
98304K 0-7,16-23

• 98304K son 96 MB: es el CCD con 3D V-Cache. Sus núcleos son 0-7,16-23.
• 32768K son 32 MB: es el otro CCD, con 8-15,24-31.

Linux numera primero un hilo de cada núcleo físico y después los segundos hilos, por lo que cada CCD aparece dividido en dos tramos. No hay que dar por hecho que la caché se encuentra en los núcleos 0-7: es necesario leer la lista en cada equipo. Esa lista es la que se utiliza más adelante con taskset.

Si aparece una sola línea, el procesador tiene un solo CCD o todos los núcleos comparten la misma L3, por lo que el problema de este artículo no aplica.

También se puede consultar mediante lscpu -e=CPU,CORE,CACHE. En este caso, el número de L3 de cada CPU es la última cifra de la columna de cachés.

2. Si existe el control del modo

ls /sys/bus/platform/drivers/amd_x3d_vcache/

Si aparece una carpeta como AMDI0101:00, el control existe. El nombre puede variar según el equipo, por lo que hay que usar el que aparezca aquí. Para ver el modo actual:

cat /sys/bus/platform/drivers/amd_x3d_vcache/*/amd_x3d_mode

El resultado es frequency o cache.

• Si solo aparecen bind, module, uevent y unbind, el controlador está en el núcleo, pero el firmware no anuncia el dispositivo. Es lo normal en procesadores sin X3D o con un solo CCD.
• Si la carpeta amd_x3d_vcache no existe, el núcleo no incluye el controlador. Hace falta Linux 6.13 o posterior (uname -r muestra la versión) con la opción CONFIG_AMD_3D_VCACHE activada.

3. Si el núcleo usa los núcleos preferidos

El modo solo cambia una clasificación. Para que sirva de algo, amd-pstate tiene que estar activo y pasar esa clasificación al planificadorref:

cat /sys/devices/system/cpu/amd_pstate/status
cat /sys/devices/system/cpu/amd_pstate/prefcore

Lo normal es que aparezca active (o guided) en la primera línea y enabled en la segunda. Si sale disabled, revisa que no tengas el parámetro amd_prefcore=disable en el arranque.

4. En qué CCD están los hilos del juego

Con el juego abierto, este comando cuenta en qué CPU se ejecutó por última vez cada hilo. El ejemplo utiliza cs2, que es el proceso de Counter-Strike 2. Para cualquier otro juego, cambia el nombre; en el caso de los juegos de Windows con Proton, suele ser el del .exe:

ps -L -o psr= -p "$(pgrep -x cs2)" | awk '
  ($1>=0 && $1<=7) || ($1>=16 && $1<=23) { c++; next }
  { o++ }
  END { print "CCD con caché:", c+0, "  otro CCD:", o+0 }'

Los tramos 0-7 y 16-23 corresponden al ejemplo. Hay que sustituirlos por los obtenidos en el paso 1. Si buena parte de los hilos está en el otro CCD y el juego da tirones, el modo cache y el fijado del juego suelen corregirlo.

Linux: activar el modo cache

Cambiarlo ahora

Escribir en ese archivo requiere permisos de administrador. El comando sudo echo cache > archivo no funciona, ya que la redirección la realiza el usuario normal. Por ello, se usa tee:

echo cache | sudo tee /sys/bus/platform/drivers/amd_x3d_vcache/AMDI0101:00/amd_x3d_mode

AMDI0101:00 es el nombre del ejemplo: hay que poner el que haya aparecido al ejecutar ls /sys/bus/platform/drivers/amd_x3d_vcache/. El cambio se aplica al instante y se puede hacer con el juego abierto. Para volver al modo de fábrica, se hace lo mismo con frequency.

Este cambio se pierde al reiniciar. Tras una suspensión, el controlador vuelve a aplicar el último modo elegidoref.

Dejarlo fijo: archivo de tmpfiles.d

systemd puede escribir un valor en un archivo en cada arranque mediante una línea de tipo w en /etc/tmpfiles.dref. Se crea de la siguiente manera:

echo 'w /sys/bus/platform/drivers/amd_x3d_vcache/AMDI0101:00/amd_x3d_mode - - - - cache' | sudo tee /etc/tmpfiles.d/x3d-cache.conf

El archivo resultante tiene una sola línea:

w /sys/bus/platform/drivers/amd_x3d_vcache/AMDI0101:00/amd_x3d_mode - - - - cache

Para aplicarlo sin reiniciar:

sudo systemd-tmpfiles --create /etc/tmpfiles.d/x3d-cache.conf

Las líneas w admiten comodinesref. Si se escribe amd_x3d_vcache/*/amd_x3d_mode en lugar del nombre exacto, la línea sigue siendo válida aunque el dispositivo cambie de nombre. Para deshacerlo, basta con borrar /etc/tmpfiles.d/x3d-cache.conf y reiniciar.

Alternativa: parámetro del núcleo

El controlador acepta el modo inicial mediante el parámetro x3d_mode, que de fábrica tiene el valor frequencyref. Su módulo se llama amd_3d_vcache, a diferencia del controlador, que se llama amd_x3d_vcache. En la línea de arranque se escribe:

amd_3d_vcache.x3d_mode=cache

Este método funciona tanto si el controlador está integrado en el núcleo como si es un módulo, ya que modprobe también lee los parámetros de la línea de arranqueref. El lugar donde se añade depende del cargador de arranque: GRUB, systemd-boot, Limine… Con el archivo de tmpfiles.d es suficiente: no hace falta utilizar las dos vías.

Alternativa: la BIOS

Muchas placas base AM5 incluyen el ajuste CPPC Dynamic Preferred Cores, que suele encontrarse dentro de las opciones SMU de AMD CBS. Sus valores son Auto, Frequency y Cacheref. Se trata de la misma preferencia, pero aplicada desde el firmware y válida para cualquier sistema operativo. Si la BIOS no ofrece esa opción, el control de Linux hace el mismo trabajo.

Fijar el juego al CCD con caché

El modo cache es una preferencia. Para evitar que un juego salga del CCD con caché, se le asigna la lista de CPU en las que puede ejecutarse, es decir, su afinidad. Para ello se utiliza la herramienta taskset, que está incluida en casi todas las distribucionesref.

En Steam

En la biblioteca, haz clic derecho sobre el juego, entra en Propiedades, ve a la pestaña General y busca el campo Opciones de lanzamiento. Usando la lista del ejemplo:

taskset -c 0-7,16-23 %command%

El uso de %command% es obligatorio, ya que Steam lo sustituye por la orden real del juego. La lista 0-7,16-23 debe obtenerse del primer paso del diagnóstico de cada equipo. Si la caché estuviera en el otro CCD, la lista sería diferente.

Los procesos hijos heredan la afinidad del padre y la mantienen al lanzar otro programaref. Por este motivo, también funciona con los juegos de Windows que se ejecutan con Proton: Proton, Wine y el .exe permanecen dentro de la misma lista.

En Lutris, Heroic y otros lanzadores, el comando taskset -c 0-7,16-23 se introduce en el campo de prefijo o wrapper de la orden. Si se hace desde una terminal, se usa: taskset -c 0-7,16-23 ./juego.

Con game-performance en CachyOS

CachyOS incluye game-performance, un script que cambia el perfil de energía a rendimiento mientras el juego está abierto y lo restablece al anterior al cerrarlo. También evita que se active el salvapantallasref. Ambas funciones se combinan en la misma línea:

taskset -c 0-7,16-23 game-performance %command%

El perfil de rendimiento aumenta el consumo y la temperatura mientras se juega.

Con GameMode

GameMode, de Feral Interactive, añadió la opción de fijar el juego a núcleos específicos en su versión 1.8ref. Según su configuración de ejemplo, la herramienta fija el juego a menos que se cambie la opción y detecta solo los X3D de dos CCD buscando los núcleos con más L3 (opción pin_cores)ref. En Steam:

gamemoderun %command%

La versión en desarrollo de GameMode añade además las opciones amd_x3d_mode_desired y amd_x3d_mode_default, que cambian el modo cache o frequency al abrir y cerrar el juegoref. A finales de octubre de 2026, la última versión publicada sigue siendo la 1.8.2, de agosto de 2024, que aún no las incluyeref.

Comprobar que funciona

Con el juego abierto:

taskset -cp "$(pgrep -x cs2)"

Debe devolver la lista seleccionada, como por ejemplo 0-7,16-23. El contador de hilos del diagnóstico debe marcar cero en el otro CCD.

Cuándo puede salir peor

• En el 7900X3D y el 9900X3D, el CCD con caché tiene seis núcleos y doce hilos. Un juego que aproveche muchos núcleos puede perder más de lo que gana.
• Si el juego compila sombreadores o carga mucho al empezar, esa parte también queda limitada a la mitad de los núcleos.
• Programas abiertos a la vez, como un directo o una grabación, compiten por los mismos núcleos si también se fijan a esa lista.

La forma más fiable es comparar el 1 % low con y sin taskset en cada juego. MangoHud lo muestra en pantalla mediante la opción fps_metrics=avg,0.01.

¿Y en Windows?

En Windows, el controlador de chipset de AMD se encarga de esta tarea e instala dos componentes para los X3D de dos CCDref:

• AMD 3D V-Cache Performance Optimizer: cambia los núcleos preferidos según el tipo de carga, igual que el modo cache o frequency de Linux.
• AMD PPM Provisioning File Driver: cuando hay un juego abierto, lo limita a un solo CCD.

Windows utiliza la Xbox Game Bar para detectar si hay un juego abierto. Cuando la Game Bar reconoce que un programa es un juego, Windows aparca los núcleos del CCD sin caché y el juego se ejecuta en el de 3D V-Cacheref.

Lo que necesita para funcionar

• El controlador de chipset de AMD al día, descargado de la web de AMD.
• Una BIOS reciente para la placa base.
• El modo de juego de Windows activadoref y la Xbox Game Bar actualizadaref.
• El plan de energía Equilibrado, el que recomienda AMD. Con el plan de Alto rendimiento, Windows no aparca los núcleosref.

Si un juego no se reconoce

Si la Game Bar no reconoce el juego, Windows no aparca el otro CCD y el juego se distribuye entre los dos, lo que provoca el mismo problema que en Linuxref. La solución consiste en abrir la Game Bar pulsando Win + G mientras el juego está en marcha y marcar en sus ajustes que esa aplicación es un juegoref.

Si quieres forzar este comportamiento en todos los programas, puedes usar el ajuste de la BIOS CPPC Dynamic Preferred Cores: la opción Auto deja que el controlador decida, Frequency prioriza el CCD sin caché y Cache prioriza el CCD con cachéref.

La gran diferencia con Linux es la detección automática de juegos. En Linux no existe una Game Bar: el modo cache se aplica a todo el sistema y, para fijar un juego concreto a un CCD, hay que usar taskset o GameMode.

Otras causas de tirones

En el mismo equipo del ejemplo surgieron otras tres causas de tirones que no tienen relación con X3D. Estas pueden ocurrir en cualquier PC con Linux.

Programas de monitorización abiertos

En este caso, Mission Center, un monitor del sistema abierto en segundo plano, consultaba la gráfica NVIDIA constantemente. Mientras el programa estaba abierto se producían microtirones, que desaparecieron al cerrarlo. La prueba es sencilla: cierra todos los monitores de sistema, los widgets de temperatura y los paneles de la gráfica, y juega un rato.

Una unidad de red que ya no existe

En /etc/fstab quedaba una carpeta compartida de un NAS con la opción x-systemd.automount. Gracias a esta opción, systemd monta la unidad la primera vez que algo accede a ellaref. El NAS ya no estaba en esa dirección IP. El monitor del sistema consultaba los discos más o menos cada once segundos y, en cada consulta, systemd intentaba montar la unidad y se quedaba esperando.

Para buscar unidades así:

systemctl list-units --type=automount
journalctl -b | grep -i -E "mount|cifs|nfs" | tail -n 30

Si una unidad apunta a un equipo que ya no existe, lo más limpio es borrar o comentar su línea en /etc/fstab y ejecutar sudo systemctl daemon-reload. Para las unidades que se mantienen, la opción x-systemd.mount-timeout=5s limita el tiempo de espera a cinco segundosref.

El perfil de energía

Cuando se usa un perfil de ahorro, el procesador tarda más en subir de frecuencia. Para ver el perfil actual:

powerprofilesctl get
cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference

Es normal que el gobernador se llame powersave cuando amd-pstate está en modo activo. Lo determinante es la preferencia de energía (EPP) que aparece en la segunda línea: performance es la opción más agresiva y power la que más ahorraref. El perfil power-saver no es buena idea para jugar. En CachyOS, game-performance activa el perfil de rendimiento solo mientras el juego está abierto.

Limitar los FPS

Fijar un límite de FPS ligeramente inferior a lo que el equipo mantiene sin esfuerzo reduce el consumo y el calor de la gráfica. A menudo, esto también hace que los tiempos de fotograma sean más regulares. En Counter-Strike 2 se puede configurar desde la consola con fps_max, por ejemplo fps_max 300. Para cualquier otro juego, MangoHud permite hacerlo mediante la opción fps_limit:

MANGOHUD_CONFIG=fps_limit=300 mangohud %command%