3D V-Cache / X3D : pourquoi le cache est devenu le cheat code ultime pour le jeu

Le cache, c’est le jeu : pourquoi les images meurent en attendant

Une image moderne de jeu est une émeute synchronisée : simulation, animation, physique, visibilité, scripts, audio, soumission d’appels de dessin,
réseau, streaming d’actifs, et une pile de pilotes qui fait semblant poliment de ne pas travailler.
Le GPU reçoit la majeure partie des reproches parce qu’il est bruyant et cher, mais beaucoup de désastres de temps d’image commencent côté CPU sous forme
de pipelines bloqués, de défauts de cache et de latence mémoire.

Voici la version sobre : les CPU sont rapides pour faire des calculs sur des données déjà proches. Ils sont mauvais pour attendre des données qui ne le sont pas.
La RAM n’est pas « lente » comme en 1998. Elle est juste éloignée en termes de latence, et la latence est ce qui tue la cohérence des temps d’image.
La moyenne d’IPS peut sembler correcte tandis que le 1% le plus bas chute parce qu’un thread continue de s’éloigner hors puce pour aller chercher des données.

Si vous êtes SRE, cela vous semblera familier. Le débit n’est pas la seule métrique. La latence de la queue est là où l’expérience utilisateur meurt.
L’équivalent dans le jeu, ce sont les temps d’image. « L’image au 99e percentile » est ce que vous ressentez.

Un défaut de cache CPU ressemble à un appel API synchrone vers une dépendance qui « répond généralement vite ». « Généralement » n’est pas un plan.
3D V-Cache est essentiellement une stratégie pour réduire la fréquence de ces appels en augmentant la taille du working set local.

Pourquoi des caches plus gros comptent plus que vous ne le pensez

Les conversations sur les performances CPU adorent les fréquences et le nombre de cœurs parce que ce sont des arguments faciles à vendre. Le cache est plus difficile à marketer :
ce n’est pas une unité que l’on ressent… jusqu’à ce que vous la ressentiez.
Le piège est que beaucoup de jeux ont des jeux de données « chauds » trop volumineux pour un L3 traditionnel mais suffisamment petits pour tenir dans un L3 beaucoup plus grand :
l’état de l’IA, les structures monde/visibilité, les grilles de broadphase physique, les rigs d’animation, les tableaux d’entités, et ce genre de « tenue de livres »
qui n’apparaît jamais dans une bande-annonce.

Quand ce jeu de données tient dans le cache, le CPU effectue du travail utile. Quand il n’y tient pas, le CPU attend.
3D V-Cache ne rend pas le CPU plus intelligent. Il rend juste le CPU moins ennuyé.

Blague n°1 : Le cache, c’est comme un bon sysadmin : invisible jusqu’à ce qu’il manque, puis soudain tout le monde a un avis.

Ce qu’est réellement le 3D V-Cache (et ce que ce n’est pas)

Le « 3D V-Cache » d’AMD est une technique d’emballage : empiler du cache L3 supplémentaire verticalement au-dessus d’un die de calcul CPU (CCD) en utilisant
des vias à travers le silicium (TSV) et du hybrid bonding. Les références « X3D » sont des SKU grand public qui sortent avec ce cache empilé.

La chose clé : ce n’est pas du « cache supplémentaire quelque part sur la carte mère ». C’est sur le package, assez proche pour se comporter comme du L3,
avec des caractéristiques de latence beaucoup plus proches du L3 que de la RAM.
Vous étendez le cache de dernier niveau pour que davantage du working set du jeu reste sur la puce, réduisant les accès mémoire hors die.

Ce que ce n’est pas

• Pas de VRAM : cela n’aide pas le GPU à stocker les textures. Cela aide le CPU à alimenter le GPU de manière plus régulière.
• Pas une bande passante magique : cela n’accélère pas la DRAM ; cela rend la DRAM moins nécessaire pour les données chaudes.
• Pas un accélérateur universel : certaines charges veulent de la fréquence, de la largeur vectorielle ou de la bande passante mémoire, et le cache ne les résoudra pas.
• Pas gratuit : empiler le cache affecte les thermiques et limite généralement les fréquences et tensions de pointe.

Le modèle mental pratique

Imaginez la « boucle chaude » d’un moteur de jeu touchant constamment quelques centaines de mégaoctets de données éparpillées.
Vos L1 et L2 sont trop petits, le L3 est la dernière chance réaliste d’éviter la RAM, et la latence DRAM est votre ennemi.
3D V-Cache augmente la probabilité qu’un accès touche le L3 au lieu de rater et d’aller en DRAM.
Cela se traduit par moins d’attentes, des temps d’image plus serrés et moins de moments « pourquoi ça a bugué là ? ».

Pourquoi les jeux aiment le L3 : la vraie histoire des charges de travail

Les jeux ne ressemblent pas aux rendus Blender ou aux encodages vidéo. Ils ne ressemblent même pas à la plupart des charges de travail « productives » de bureau.
Les jeux sont un mélange de :

• Beaucoup de petites tâches avec des délais stricts (terminer l’image à temps).
• Accès mémoire irréguliers (pointer chasing, graphes de scène, listes d’entités).
• Points de synchronisation (thread principal qui attend les workers, GPU qui attend la soumission CPU).
• Streaming d’actifs et décompression en rafales.

Dans cet environnement, le CPU est souvent lié par la latence mémoire sur le chemin critique. C’est pourquoi vous verrez les puces X3D
gagner le plus dans les titres à simulation lourde et beaucoup d’entités, ou en contexte compétitif en 1080p/1440p où le GPU n’est pas le facteur limitant.

« Plus de cache » devient « moins d’attente »

La saccade est souvent une micro-histoire d’une cascade de défauts de cache :
un pointer chase rate le L2, rate le L3, va en DRAM ; la ligne récupérée contient des données dont vous aviez besoin il y a trois microsecondes ;
maintenant votre cœur est prêt à travailler… sur l’image suivante.
Rendez le L3 suffisamment grand, et une quantité surprenante de cette chaîne n’arrive même pas.

La stabilité des temps d’image bat le FPS maximal

La signature X3D n’est souvent pas une IPS maximale supérieure mais des 1% et 0,1% plus solides—moins de latence extrême.
Cela se voit comme une « sensation plus fluide » même quand les moyennes sont proches.
Et c’est pourquoi les personnes qui ne benchmarkent qu’avec l’IPS moyenne ratent parfois ce qui se passe vraiment.

Où X3D n’aide pas (ou aide moins)

Si vous êtes limité par le GPU (4K ultra avec ray tracing, upscaling désactivé, ou simplement un GPU milieu de gamme), le cache CPU n’est pas le goulot.
Si vous faites du calcul productif vectorisé parcourant de grands tableaux (certains codes scientifiques),
la bande passante et le débit d’instructions dominent.

Aussi : si votre moteur de jeu est déjà bien structuré avec une forte localité des données, la valeur marginale d’un L3 plus grand est plus faible.
C’est rare, mais ça arrive.

Les compromis : fréquence, thermiques et « ça dépend »

Les CPU X3D sont conçus avec des contraintes. L’empilement du cache change le flux thermique et limite la marge de tension.
Vous verrez typiquement des fréquences boost plus basses que les homologues non-X3D, et l’overclocking est souvent restreint.
En retour, vous obtenez un type de performance différent : moins de sensibilité à la latence mémoire et de meilleurs taux de hit dans le cache.

Réalité thermique

La couche de cache empilée n’est pas que de la logique ; c’est une structure physique affectant la densité thermique.
La chaleur doit traverser plus de matière avant d’atteindre le spreader.
Cela ne signifie pas que X3D est « plus chaud » d’une manière simpliste, mais cela signifie que le comportement de boost, les fréquences soutenues et la qualité du refroidissement
interagissent différemment.

Particularités de plateforme et d’ordonnanceur

Les pièces X3D multi-CCD peuvent avoir un cache asymétrique : un CCD avec cache empilé, un autre sans (selon la génération/SKU).
Cela force des décisions de planification : idéalement, les threads de jeu doivent se placer sur le CCD riche en cache.
Windows s’est amélioré là-dessus avec des drivers de chipset et des heuristiques Game Mode, mais vous pouvez encore perdre des performances
si l’OS distribue les threads « équitablement » plutôt que « intelligemment ».

Réglage mémoire : moins important, pas hors-jeu

Un L3 plus grand réduit la dépendance à la DRAM pour les données chaudes, donc la vitesse RAM est souvent moins critique que sur les pièces non-X3D.
Mais « moins critique » ne veut pas dire « sans importance ». Des timings mauvais, une EXPO/XMP instable, ou des ratios fabric non optimaux peuvent toujours vous gâcher la journée,
surtout en réglages esports CPU-lourds.

Faits & histoire : le contexte que l’on oublie

Le cache n’est pas soudainement devenu important en 2022. Il a discrètement dirigé la scène depuis des décennies.
Quelques points concrets de contexte à garder en tête :

1. Les premiers CPU tournaient proches de la vitesse de la RAM. À mesure que les fréquences CPU ont accéléré, « le mur mémoire » est devenu une contrainte décisive.
2. Le cache L2 était autrefois hors-die. Dans les années 1990, de nombreux systèmes avaient des puces de cache externes ; déplacer le cache on-die a été un saut de performance majeur.
3. Les puces serveur ont cherché le cache bien avant les joueurs. De grands caches de dernier niveau étaient une tactique standard pour les bases de données et VM.
4. Les consoles ont entraîné les développeurs à viser des budgets CPU fixes. Cela a poussé les moteurs vers un pacing d’image prévisible, mais la variabilité PC réintroduit les douleurs cache/mémoire.
5. L’ère chiplet d’AMD a rendu la topologie du cache visible. Les designs CCD/IO-die séparés ont rendu les différences de latence plus prononcées—et mesurables.
6. L’empilement 3D n’est pas nouveau ; il est maintenant abordable à grande échelle. Les TSV et le packaging avancé existent depuis des années, mais l’économie grand public s’est enfin alignée.
7. Les jeux ont évolué vers une simulation plus lourde. Plus d’entités, plus de mondes ouverts, plus de systèmes d’arrière-plan—plus d’état chaud à garder proche.
8. L’analyse des temps d’image a mûri. L’industrie est passée de l’IPS moyen aux temps d’image en percentiles, exposant la latence de queue liée au cache.

Si vous ne retenez rien d’autre : X3D n’a pas « cassé » les benchs de jeu. Il a exposé ce qui était déjà vrai—la latence mémoire a été le percepteur
des performances CPU modernes. X3D a juste réduit votre revenu imposable.

Mode d’action diagnostic rapide : quoi vérifier en premier/deuxième/troisième

Voici le workflow « arrêtez de deviner ». Vous pouvez le faire sur une machine de jeu, une machine de bench, ou une flotte de postes.
L’objectif est de décider : limité GPU, limité CPU (calcul), limité CPU (mémoire/latence), ou « quelque chose cloche ».

1) D’abord : identifier le limiteur (GPU vs CPU) en 2 minutes

• Baissez la résolution ou le scale de rendu. Si les IPS changent peu, vous êtes limité par le CPU. Si les IPS sautent, vous étiez limité par le GPU.
• Surveillez l’utilisation GPU. ~95–99% soutenu suggère un goulot GPU. Une utilisation oscillante avec des pics de frame indique souvent des problèmes de pacing côté CPU.

2) Ensuite : confirmer si la limite CPU est liée au cache/à la latence

• Vérifiez les percentiles des temps d’image. Si les moyennes sont correctes mais que les 1% bas sont moches, soupçonnez la latence mémoire et la planification.
• Recherchez un taux élevé de context switches et de migrations. Des threads qui sautent entre cœurs/CCD peuvent anéantir la localité du cache.
• Mesurez la latence DRAM et les ratios fabric. Une mémoire mal configurée peut faire « sentir » un CPU plus lent que sa fiche technique.

3) Troisième : vérifier les hypothèses de plateforme

• Paramètres BIOS : stabilité EXPO/XMP, CPPC preferred cores, réglages PBO, limites thermiques.
• OS : driver de chipset correct, comportement d’ordonnancement à jour, Game Mode, plan d’alimentation pas coincé en « économie d’énergie ».
• Bruit de fond : hooks d’overlay, outils de capture, logiciels de contrôle RGB avec boucles de polling (oui, toujours).

4) Décider : acheter/ajuster/retour en arrière

Si vous êtes limité par le CPU et que le profil hurle « attente mémoire », X3D est souvent la solution la plus propre : il change la forme du goulot.
Si vous êtes limité par le GPU, n’achetez pas un X3D pour régler ça. Dépensez pour le GPU, ajustez les réglages graphiques, ou acceptez la physique.

Tâches pratiques : commandes qui tranchent les débats

Ce sont des commandes réelles et exécutables. Chacune inclut ce que la sortie signifie et la décision à en tirer.
La plupart sont orientées Linux parce que Linux dit honnêtement ce qu’il fait, mais beaucoup s’appliquent conceptuellement à Windows.
Utilisez-les pour benchmarker, dépanner et prouver si le cache est l’histoire.

Task 1: Confirm CPU model and cache sizes

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|Socket|L1d|L1i|L2|L3'
Model name:                           AMD Ryzen 7 7800X3D 8-Core Processor
CPU(s):                               16
Thread(s) per core:                   2
Core(s) per socket:                   8
Socket(s):                            1
L1d cache:                            256 KiB (8 instances)
L1i cache:                            256 KiB (8 instances)
L2 cache:                             8 MiB (8 instances)
L3 cache:                             96 MiB (1 instance)

Signification : La taille du L3 est le point d’attention. Les pièces X3D montrent typiquement un L3 exceptionnellement grand (par ex. 96 MiB).

Décision : Si le L3 est « normal » (par ex. 32 MiB) et que votre charge est sensible à la latence, n’attendez pas un comportement à la X3D.

Task 2: Verify memory speed and timings are what you think they are

cr0x@server:~$ sudo dmidecode -t memory | egrep 'Speed:|Configured Memory Speed:'
Speed: 4800 MT/s
Configured Memory Speed: 6000 MT/s
Speed: 4800 MT/s
Configured Memory Speed: 6000 MT/s

Signification : « Speed » est la cote du module ; « Configured » est ce que vous exécutez réellement.

Décision : Si la vitesse configurée reste au défaut JEDEC, activez EXPO/XMP (puis validez la stabilité).
X3D est tolérant, pas immunisé.

Task 3: Check current CPU frequency behavior under load

cr0x@server:~$ lscpu | grep 'MHz'
CPU MHz:                               4875.123

Signification : Instantané uniquement—utilisez-le pour détecter un cas évident de « fréquence bloquée basse ».

Décision : Si les clocks sont anormalement basses pendant le jeu, vérifiez le plan d’alimentation, le thermal throttling, ou des limites BIOS.

Task 4: Detect thermal throttling signals (kernel view)

cr0x@server:~$ dmesg -T | egrep -i 'thermal|thrott'
[Sat Jan 10 10:12:41 2026] thermal thermal_zone0: critical temperature reached, shutting down

Signification : Exemples extrêmes montrés. Sur des systèmes plus doux, vous verrez des throttling ou des avertissements de zones thermiques.

Décision : Si vous voyez des événements thermiques, corrigez le refroidissement ou ajustez les limites avant de blâmer le cache ou le GPU.

Task 5: Inspect CPU scheduling and migrations (cache locality killer)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 921344  81240 612340    0    0     0     1  412  980 12  4 83  0  0
 3  0      0 920112  81240 612900    0    0     0     0  460 1760 18  5 77  0  0
 2  0      0 919880  81240 613020    0    0     0     0  455 2105 21  6 73  0  0
 4  0      0 919600  81240 613200    0    0     0     0  470 3500 28  7 65  0  0
 2  0      0 919300  81240 613500    0    0     0     0  465 1400 16  5 79  0  0

Signification : Faites attention aux pics de cs (context switches). Un switching élevé peut indiquer du churn de threads et une mauvaise localité.

Décision : Si les context switches explosent pendant les moments de saccade, investiguez les logiciels d’arrière-plan, les overlays, et les stratégies de pinning/ordonnancement.

Task 6: Find which threads burn CPU time (and whether it’s a single-thread wall)

cr0x@server:~$ top -H -p $(pgrep -n game.bin)
top - 10:21:13 up  2:14,  1 user,  load average: 6.20, 5.80, 5.10
Threads:  64 total,   2 running,  62 sleeping,   0 stopped,   0 zombie
%Cpu(s): 38.0 us,  4.0 sy,  0.0 ni, 58.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
42210 cr0x      20   0 5412280 1.2g 21400 R  98.7   7.6   2:01.22 MainThread
42233 cr0x      20   0 5412280 1.2g 21400 S  22.1   7.6   0:24.10 RenderWorker

Signification : Un « MainThread » proche de 100% suggère un goulot mono-thread—souvent sensible au cache et à la latence.

Décision : Si un thread est le mur, chassez le pacing d’image, le comportement du cache et l’ordonnancement ; plus de GPU n’aidera pas.

Task 7: Sample CPU hotspots and whether you’re stalling (perf)

cr0x@server:~$ sudo perf top -p $(pgrep -n game.bin)
Samples: 12K of event 'cycles', Event count (approx.): 8512390123
  9.80%  game.bin        [.] UpdateVisibility
  7.45%  game.bin        [.] PhysicsBroadphase
  6.12%  game.bin        [.] AI_Tick
  4.22%  libc.so.6       [.] memcpy
  3.70%  game.bin        [.] SubmitDrawCalls

Signification : Cela vous dit où vont les cycles. Si vous voyez beaucoup de memcpy et de fonctions de traversée, le comportement du cache compte.

Décision : Si les hotspots sont traversal/visibilité/IA et non du calcul pur, un cache à la X3D peut aider plus que la fréquence brute.

Task 8: Check hardware counters for cache misses (high-level view)

cr0x@server:~$ sudo perf stat -e cycles,instructions,cache-references,cache-misses -p $(pgrep -n game.bin) -- sleep 10
 Performance counter stats for process id '42210':

   21,503,112,044      cycles
   28,774,550,112      instructions              #    1.34  insn per cycle
    1,903,112,881      cache-references
      214,332,910      cache-misses              #   11.26% of all cache refs

      10.002131833 seconds time elapsed

Signification : Des taux de défauts de cache élevés et un IPC bas indiquent souvent une attente sur la mémoire.

Décision : Si le taux de défauts est élevé pendant les scènes qui saccadent, un L3 plus grand (ou une meilleure localité) est une solution rationnelle.

Task 9: Detect NUMA/CCD effects (where memory accesses go)

cr0x@server:~$ numactl --hardware
available: 1 nodes (0)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 0 size: 31944 MB
node 0 free: 21012 MB

Signification : Sur beaucoup de desktops vous verrez un seul nœud NUMA, mais sur certaines plateformes vous en verrez plusieurs.

Décision : Si plusieurs nœuds existent, les accès cross-node augmentent la latence. Envisagez du pinning ou assurez-vous que le jeu reste local.

Task 10: Pin a process to a subset of CPUs to test scheduling hypotheses

cr0x@server:~$ taskset -cp 0-7 $(pgrep -n game.bin)
pid 42210's current affinity list: 0-15
pid 42210's new affinity list: 0-7

Signification : Vous contraignez les threads aux cœurs 0–7. Sur systèmes multi-CCD cela peut vous garder sur un seul CCD (selon le mapping).

Décision : Si le pacing s’améliore quand on pinne, vous aviez probablement des problèmes de migration/localité de cache. Corrigez les réglages du scheduler ou la pile BIOS/driver.

Task 11: Validate storage latency during stutter hunts (asset streaming)

cr0x@server:~$ iostat -xz 1 5
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.20    0.00    3.40    6.80    0.00   71.60

Device            r/s     w/s   rKB/s   wKB/s  avgrq-sz avgqu-sz   await  %util
nvme0n1         120.0    35.0  8200.0  2400.0      80.0     2.10   12.40  92.00

Signification : Un await élevé et un %util élevé durant les saccades suggèrent que le disque est saturé ou que la latence monte.

Décision : Si le stockage est le coupable, X3D ne vous sauvera pas. Corrigez les réglages de streaming, déplacez le jeu sur un stockage plus rapide, ou réduisez l’I/O en arrière-plan.

Task 12: Check memory pressure and swapping (instant stutter generator)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi       25Gi       1.2Gi       1.1Gi       4.8Gi       4.2Gi
Swap:          8.0Gi      2.5Gi       5.5Gi

Signification : L’utilisation du swap n’est pas toujours fatale, mais l’échange actif pendant le jeu est généralement catastrophique pour les temps d’image.

Décision : Si le swap est utilisé, fermez les apps gourmandes en mémoire, ajoutez de la RAM, ou corrigez les fuites. Le cache ne bat pas le disque.

Task 13: Observe major page faults (often shows streaming/decompression or memory issues)

cr0x@server:~$ pidstat -r -p $(pgrep -n game.bin) 1 5
Linux 6.5.0 (server)  01/10/2026  _x86_64_  (16 CPU)

10:27:01 AM   UID       PID  minflt/s  majflt/s     VSZ     RSS   %MEM  Command
10:27:02 AM  1000     42210    120.00      0.00 5412280 1254300   3.92  game.bin
10:27:03 AM  1000     42210    180.00      4.00 5412280 1259800   3.94  game.bin
10:27:04 AM  1000     42210    160.00      0.00 5412280 1259900   3.94  game.bin

Signification : Les fautes majeures (majflt/s) indiquent que le process attend des pages backing sur disque—mauvais pour le pacing temps-réel.

Décision : Si les fautes majeures corrèlent avec les hics, réduisez la pression mémoire, assurez-vous que les fichiers du jeu sont sur un stockage rapide, et évitez les scans agressifs en arrière-plan.

Task 14: Measure memory latency quickly (simple heuristic via lmbench if present)

cr0x@server:~$ /usr/bin/lat_mem_rd 128 4
"stride=128 bytes
128.000000 3.2
256.000000 3.4
512.000000 3.5
1024.000000 3.7
2048.000000 4.1
4096.000000 5.0
8192.000000 7.2
16384.000000 10.8
32768.000000 14.5
65536.000000 62.0
131072.000000 66.0

Signification : La latence saute quand le working set dépasse les niveaux de cache ; le grand saut vers 64 MiB+ indique souvent la sortie du LLC et l’accès à la DRAM.

Décision : Si le jeu chaud traverse la frontière du LLC sur une non-X3D mais reste à l’intérieur sur X3D, vous avez trouvé le « cheat code ».

Task 15: Verify PCIe link speed (because sometimes it’s just broken)

cr0x@server:~$ sudo lspci -vv | sed -n '/VGA compatible controller/,/Capabilities/p' | egrep 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s, Width x16

Signification : Si le GPU tourne accidentellement en x4 ou à basse vitesse, vous aurez des performances bizarres et des saccades.

Décision : Corrigez le choix de slot physique, les réglages BIOS, ou les câbles riser avant de commencer à adorer le cache.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse (« C’est lié au calcul »)

Un studio de taille moyenne a déployé un lab CI de machines de build-et-benchmark pour attraper les régressions de performance tôt.
Le labo avait un mélange de CPU à haute fréquence et quelques variantes riches en cache. Les résultats initiaux semblaient bruyants, et l’équipe a décidé que le bruit venait de la « variance du driver GPU ».
Ils ont donc normalisé tout autour de l’IPS moyen et ont clos le dossier.

Quelques semaines plus tard, un patch est sorti et les joueurs se sont plaints de « hitchs aléatoires » dans les zones peuplées.
L’IPS moyen dans leurs dashboards internes semblait correct. La direction a obtenu ce qu’elle voulait : un graphique qui n’effrayait pas.
Le support a obtenu ce qu’il ne voulait pas : mille tickets qui sonnaient tous comme de la superstition.

Quand le SRE a finalement tiré une trace, le hitch coïncidait avec un stall du thread principal déclenché par des mises à jour de visibilité d’entités.
Le stall n’était pas assez grand pour écraser l’IPS moyen, mais suffisament pour démolir les 1% bas.
Sur les CPU riches en cache, le jeu chaud restait dans le LLC et le stall a presque disparu. Sur les CPU à haute fréquence mais plus petits caches, il déversait en DRAM et provoquait un pic.

La mauvaise hypothèse était simple : « Si le CPU est à 60% d’utilisation globale, il ne peut pas être limité par le CPU. »
Mais l’utilisation est un menteur dans les systèmes temps-réel. Un thread saturé sur le chemin critique est un arrêt complet, même si quinze autres threads sirotent un café.

La correction n’a pas été « acheter des X3D pour tout le monde ». Ils ont modifié la porte de benchmark pour inclure les percentiles de temps d’image et ajouté un test de régression spécifiquement pour le scénario encombré.
Ils ont aussi refactorisé la structure de visibilité pour améliorer la localité. La performance a cessé d’être mystérieuse une fois qu’ils ont mesuré la bonne chose.

Mini-récit 2 : L’optimisation qui a mal tourné (« On compacte tout »)

Une société de services financiers avait un outil interne de visualisation 3D utilisé pour les salles d’incident : topologie en direct, métriques en streaming, et une timeline fancy.
Il tournait sur les desktops des ingénieurs et devait rester réactif en partage d’écran.
Quelqu’un l’a profilé et a trouvé beaucoup de temps passé à parcourir des graphes d’objets—territoire classique des défauts de cache—alors ils ont tenté une réécriture « orientée données ».

Ils ont compacté les structures agressivement, basculé vers des bitfields, et compressé les IDs.
Sur le papier, cela réduisait significativement l’empreinte mémoire. En microbenchmarks, l’itération s’est accélérée.
En production, le pacing d’image s’est empiré. Pas tout le temps. Juste assez pour être exaspérant.

Le retour de bâton venait d’un détail que personne n’a respecté : la réécriture a augmenté la branchiness et introduit davantage d’indirections de pointeurs sur le chemin chaud.
Les structures plus petites ont amélioré la densité cache, mais les étapes de décodage supplémentaires ont créé des chaînes de dépendance et plus de branches imprévisibles.
Le CPU a passé moins de cycles à attendre la DRAM mais plus de cycles à staller sur des mispredicts et des opérations sérialisées.

Sur des CPU de classe X3D, le changement paraissait « correct » parce que le L3 agrandi masquait une partie des dégâts.
Sur des CPU normaux, cela ressemblait à une régression. L’équipe avait accidentellement optimisé pour le profil hardware le plus favorable.

La solution finale était ennuyeuse : revenir sur le packing astucieux dans le chemin chaud, le garder dans le stockage froid, et restructurer les boucles pour réduire l’indirection.
Ils ont appris la leçon adulte : une optimisation qui gagne un microbenchmark peut encore perdre le produit.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (pinning et invariants)

Une entreprise fournissant de la visualisation distante pour CAO avait une flotte de postes avec des SKU CPU mixtes,
y compris quelques pièces avec cache empilé pour les sessions sensibles à la latence. Les utilisateurs se plaignaient que « certaines machines sont fluides, d’autres collantes ».
Le service était identique. Les GPU étaient identiques. Le support accusait le réseau parce que c’est toujours le réseau.

Un SRE a écrit trois invariants : (1) le processus de session doit rester sur un seul domaine NUMA, (2) le thread de rendu doit préférer les cœurs riches en cache quand présents,
(3) pas de jobs de maintenance en arrière-plan pendant les sessions actives.
Puis ils ont appliqué ces invariants avec un petit wrapper qui réglait l’affinité CPU et les priorités cgroup.

La variance de performance a chuté immédiatement. Pas parce qu’ils ont « optimisé » quelque chose—mais parce qu’ils ont enlevé l’aléatoire.
La migration de threads détruisait la localité du cache et traversait parfois des chemins d’interconnexion plus lents.
Sur les CPU empilés en cache, les migrations étaient moins dommageables ; sur les machines à cache plus petit, elles étaient brutales.

La solution n’était pas glamour. Elle n’a pas non plus demandé d’acheter du matériel neuf.
Elle a demandé d’admettre que l’ordonnancement fait partie de la conception système, pas un détail d’implémentation.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: High average FPS, terrible 1% lows

Cause racine : Stalls du thread principal dus à des défauts de cache, streaming d’actifs, ou migration de threads ; les moyennes masquent la latence extrême.

Correctif : Benchmarkez les percentiles des temps d’image ; réduisez les migrations (updates driver, Game Mode, tests d’affinité) ; assurez la stabilité de la RAM ; envisagez X3D pour les titres limités par la latence.

2) Symptom: X3D chip “doesn’t outperform” non-X3D in your game

Cause racine : Vous êtes limité par le GPU, ou le jeu tient déjà son working set dans un cache normal, ou le scénario de bench n’est pas CPU-limité.

Correctif : Baissez la résolution/scale pour tester la limite CPU ; choisissez des scènes CPU-lourdes ; comparez les 1% bas, pas seulement les moyennes.

3) Symptom: Performance regressed after enabling EXPO/XMP

Cause racine : Instabilité mémoire causant des corrections d’erreurs, des retries, des événements type WHEA, ou des subtilités temporelles qui apparaissent comme des saccades.

Correctif : Rétablissez la vitesse/timings mémoire ; mettez à jour le BIOS ; validez avec des stress tests ; gardez des ratios fabric raisonnables pour la plateforme.

4) Symptom: Random stutters that don’t correlate with CPU or GPU utilization

Cause racine : Pics de latence de stockage, fautes de page, scans en arrière-plan, ou hooks de capture/overlay provoquant des stalls périodiques.

Correctif : Vérifiez iostat, les fautes majeures, et les services en arrière-plan ; déplacez le jeu sur un SSD rapide ; désactivez les tâches agressives en arrière-plan pendant le jeu.

5) Symptom: Multi-CCD X3D performs worse than expected

Cause racine : L’ordonnanceur place des threads critiques sur le CCD sans V-Cache ; le hopping de thread détruit la localité.

Correctif : Assurez-vous que les drivers de chipset et l’OS sont à jour ; utilisez Game Mode ; testez avec affinité ; évitez les « optimizers » de cœurs manuels qui combattent le scheduler.

6) Symptom: Benchmark results vary wildly run to run

Cause racine : Variance de boost thermique, tâches en arrière-plan, scène de jeu inconsistante, compilation de shaders, ou limites d’alimentation.

Correctif : Runs d’échauffement ; verrouillez le plan d’alimentation ; journalisez températures/fréquences ; videz le cache de shaders ou précompilez ; gardez le chemin de test identique.

7) Symptom: You “feel” input lag even at high FPS

Cause racine : Jitter dans le pacing d’image, pas l’IPS brute ; les stalls CPU peuvent retarder la soumission ; les réglages de buffering peuvent amplifier cela.

Correctif : Suivez les temps d’image ; réduisez les stalls CPU (cache/localité) ; ajustez les options latence en jeu ; assurez-vous que VRR et la stratégie de cap sont sensées.

Blague n°2 : Optimiser pour l’IPS moyenne, c’est comme se vanter que votre service a « cinq neuf » de disponibilité parce qu’il était up pendant votre pause déjeuner.

Checklists / plan étape par étape

A. Buying decision checklist (X3D or not)

1. Définissez votre cible : compétitif 1080p/1440p haut rafraîchissement (probablement CPU) vs 4K visuel (probablement GPU).
2. Identifiez vos pires jeux : ceux avec des saccades, pas ceux qui benchent joliment.
3. Testez la limite CPU : baissez la résolution/scale ; si l’IPS change peu, le CPU est le limiteur.
4. Regardez les percentiles des temps d’image : si les 1% bas sont mauvais, le cache est suspect.
5. Vérifiez les contraintes de plateforme : qualité du refroidissement, maturité du BIOS, et si vous acceptez d’échanger des clocks max contre de la cohérence.
6. Choisissez X3D quand : vous êtes CPU-limité dans des scènes réelles, surtout avec simulation lourde ou grand nombre d’entités.
7. Évitez X3D quand : vous êtes toujours GPU-limité, ou votre charge principale profite surtout de la fréquence en productivité où le cache n’aide pas.

B. Benchmark methodology checklist (stop lying to yourself)

1. Utilisez la même sauvegarde / route / replay.
2. Faites un run d’échauffement pour éviter le biais de compilation de shaders.
3. Enregistrez les temps d’image et les percentiles, pas seulement l’IPS moyenne.
4. Journalisez clocks et températures pour expliquer la variance.
5. Faites au moins 3 itérations ; gardez la médiane, pas la meilleure.
6. Changez une variable à la fois (CPU, RAM, réglage BIOS).

C. Tuning checklist for X3D systems (safe, boring, effective)

1. Mettez à jour le BIOS vers une release stable pour votre plateforme.
2. Installez le driver de chipset ; assurez-vous que les fonctionnalités de l’ordonnanceur OS sont activées.
3. Activez EXPO/XMP, puis validez la stabilité ; si instable, réduisez vitesse/timings.
4. Utilisez un plan d’alimentation sensé ; évitez des limites « minimum processor state » excessives.
5. Gardez un refroidissement compétent ; évitez les cliffs thermiques qui provoquent une oscillation de boost.
6. N’empilez pas d’utilitaires « optimizers » qui pinnent les threads aléatoirement.
7. Validez avec de vrais jeux et les percentiles des temps d’image.

Une citation sur la fiabilité à garder à portée

Idée paraphrasée — Werner Vogels : vous devez planifier l’échec comme une condition normale, pas comme une exception.

Cet état d’esprit s’applique clairement au travail sur les performances de jeu. Planifiez les défauts de cache, les bizarreries d’ordonnancement et les stalls de streaming comme des conditions normales.
X3D est efficace parce qu’il rend le cas courant moins punitif, pas parce qu’il rend l’échec impossible.

FAQ

Est-ce que 3D V-Cache augmente l’IPS moyen ou seulement les 1% bas ?

Les deux peuvent s’améliorer, mais le gain le plus fiable se trouve sur les 1% et 0,1%—la stabilité des temps d’image.
Si votre jeu est déjà GPU-limité, rien ne bougera beaucoup.

X3D est-il « meilleur qu’Intel » pour le jeu ?

Dans de nombreux titres CPU-limités, les pièces X3D performent extrêmement bien parce que le taux de hit dans le cache domine.
Mais la plateforme, le SKU et le jeu importent. Comparez dans votre gamme de prix et testez des scénarios CPU-limits, pas des captures d’écran 4K ultra.

Pourquoi un L3 supplémentaire aide parfois plus les jeux que les apps productives ?

Beaucoup de charges productives sont en streaming et prévisibles—idéal pour le prefetching et la bande passante.
Beaucoup de charges de jeu sont irrégulières et pointer-heavy—propices aux défauts de cache et aux stalls sur la latence.

Ai-je encore besoin de RAM rapide avec X3D ?

Vous avez besoin d’abord d’une RAM stable. Ensuite, X3D tend à être moins sensible à la vitesse RAM que les CPU non-X3D,
mais le tuning mémoire peut encore compter dans les scénarios compétitifs à haut rafraîchissement.

Puis-je overclocker les puces X3D comme d’habitude ?

Typiquement non de la manière classique « augmenter le multiplicateur et la tension » ; l’empilement a des contraintes de tension/thermie.
Vous aurez peut-être des options comme le tuning lié à PBO selon la plateforme et la génération, mais la stratégie sûre est de régler pour la stabilité et les thermiques.

Pourquoi certains benchmarks montrent-ils de petits gains pour X3D ?

Parce que le benchmark est GPU-limité, utilise une scène qui tient dans un cache normal, ou se concentre sur l’IPS moyenne.
X3D brille quand le working set est grand et irrégulier et quand le pacing d’image compte.

L’ordonnancement des threads est-il vraiment si important ?

Oui. La localité du cache est physique. Si un thread critique migre, il peut payer une pénalité de cache froid.
Sur les systèmes multi-CCD, il peut aussi payer une pénalité de topologie. Si vous voyez de la variance, l’ordonnancement est un suspect principal.

X3D aidera-t-il à réduire les saccades liées à la compilation de shaders ?

Pas beaucoup. La compilation de shaders est souvent CPU-intensive et I/O-intensive d’une manière qui n’est pas résolue par plus de L3.
On la réduit avec des caches de shaders, la précompilation, des updates driver/jeu, et le débit stockage/CPU—pas principalement par la taille du cache.

Quelle est la façon la plus simple de savoir si je suis CPU-bound ?

Baissez la résolution ou le scale de rendu et retestez la même scène.
Si l’IPS change peu, le GPU n’était pas le limiteur. Regardez ensuite les percentiles des temps d’image pour voir si c’est latence/pacing.

Dois-je acheter X3D pour jouer en 4K ?

Si vous êtes majoritairement GPU-limité en 4K, X3D est rarement le meilleur rapport qualité/prix pour l’IPS pure. Il peut aider pour la cohérence dans certains titres,
mais votre argent appartient généralement au GPU en premier lieu.

Prochaines étapes pratiques

Si vous voulez l’effet « cheat code » de X3D, gagnez-le par la mesure :
choisissez une scène qui saccade, capturez les temps d’image, et décidez si vous avez affaire à de la latence CPU, à la saturation GPU, à des stalls de stockage, ou à un chaos d’ordonnancement.
Puis agissez de manière décisive.

• Si vous êtes GPU-limité : ajustez les graphismes, upgradez le GPU, limitez le framerate pour la cohérence, et arrêtez de blâmer le CPU.
• Si vous êtes CPU-limité avec une vilaineté dans la queue : privilégiez les CPU riches en cache, réduisez la migration de threads, et gardez la mémoire stable.
• Si vous êtes limité par des « saccades aléatoires » : vérifiez le swapping, la latence de stockage, les hooks en arrière-plan, et le comportement thermique avant d’acheter quoi que ce soit.
• Si vous gérez une flotte : imposez des invariants (drivers, BIOS, plans d’alimentation), journalisez les percentiles des temps d’image, et ne laissez pas les moyennes piloter votre organisation.

3D V-Cache n’est pas de la magie. C’est un avantage très spécifique : il transforme une charge messy et sensible à la latence en une charge qui se comporte comme si elle avait son affaire en ordre.
Pour le jeu, c’est suffisamment proche de la magie pour que les gens continuent d’en parler comme tel.