Pourquoi Windows et Linux peuvent donner des FPS différents sur le même CPU

Les FPS sont un symptôme ; le temps d’image est la maladie

« FPS différents » est généralement un raccourci pour un ensemble d’enjeux distincts :

• FPS moyen (facile à afficher, facile à manipuler avec des benchmarks).
• 1 % / 0,1 % lows (à quel point ça peut être mauvais quand l’OS et les pilotes ne s’accordent pas avec votre charge).
• Pacing des images (livraison régulière des images vs un désordre saccadé).
• Latence entrée→pixel (combien de temps votre clic met pour devenir un pixel).

Deux systèmes peuvent avoir des FPS moyens identiques et pourtant se ressentir radicalement différemment parce que l’un a une distribution du temps d’image plus resserrée. L’OS compte parce que c’est lui qui décide qui tourne quand, sur quel cœur, à quelle fréquence, et avec quels interruptions qui débarquent au pire moment.

Voici l’état d’esprit opérationnel : une image de jeu est une mini chaîne de production. Vous avez un thread principal, des threads de rendu, des threads travailleurs, la soumission au pilote, l’exécution GPU, le present, la composition, et parfois des couches de traduction. Si une étape se bloque, toute la chaîne hoquette.

L’OS est le gestionnaire de la chaîne. Manager différent, goulots différents.

Faits intéressants et contexte historique

Ce ne sont pas des anecdotes pour la beauté du geste. Elles expliquent pourquoi certains choix de conception existent et pourquoi ils sont difficilement « corrigeables » aujourd’hui.

1. Les API jeu Windows ont façonné les priorités des pilotes. DirectX a dominé le jeu PC pendant des décennies, et les éditeurs ont optimisé pilotes et outils pour Windows en conséquence.
2. Le graphisme sur Linux a connu plusieurs ères. Le modèle X11, puis les compositeurs, puis Wayland ; chaque changement a amélioré certains chemins de latence et compliqué d’autres.
3. L’ordonnanceur Windows a été optimisé pour l’interactivité bureau depuis longtemps. Le boost des applications au premier plan et l’ordonnancement multimédia existent parce que les applis de bureau (puis les jeux) avaient besoin de réactivité.
4. Le CFS de Linux a été optimisé pour l’équité et le débit. C’est excellent pour les charges mixtes, mais « équitable » n’est pas toujours « latence minimale maintenant ».
5. Les timers haute résolution ont changé le débogage de performance. À mesure que les timers se sont affinés, les développeurs ont commencé à utiliser le busy-waiting et le polling haute fréquence ; c’est une grenade pour la consommation et l’ordonnancement.
6. Les CPU modernes ont forcé une complexité de politiques d’alimentation au niveau OS. Turbo, cœurs E/P, CPPC, états C profonds — ces éléments introduisent des points de décision où les valeurs par défaut de l’OS divergent.
7. Les modèles de pilotes diffèrent. WDDM de Windows met l’accent sur la préemption, l’ordonnancement et le contrôle au niveau OS ; Linux a une répartition différente entre DRM kernel, Mesa et blobs fournisseur.
8. Le « plein écran exclusif » est devenu un champ de bataille. Windows a introduit des « optimisations plein écran » pour réduire les changements de mode ; parfois génial, parfois catastrophique. Les règles de composition de Linux sont encore différentes.

D’où viennent les différences entre OS (la vraie liste)

1) Ordonnancement CPU : qui tourne, où et pendant combien de temps

Les jeux ne sont pas uniformément parallèles. Beaucoup sont encore limités par un thread principal ou quelques threads chauds avec un ordre strict. Cela rend les décisions d’ordonnancement visibles.

• Windows dispose d’un ensemble mûr d’heuristiques pour les applis au premier plan, l’ordonnancement de classe multimédia, et « donner à l’élément actif une meilleure chance de tourner ». Ce n’est pas parfait, mais c’est intentionnel.
• Linux avec CFS est extrêmement bon pour l’équité et l’utilisation. Mais l’équité peut signifier que votre thread chaud partage le temps plus « démocratiquement » avec du travail en arrière-plan que vous ne soupçonniez pas (comme un compositeur, un onglet de navigateur, ou un compilateur de cache de shaders).

Quand vous voyez des pics de temps d’image toutes les quelques secondes, suspectez une interférence d’ordonnancement : un thread kernel, une tempête d’interruptions, un événement de reclaim mémoire, ou un service d’arrière-plan faisant du « travail utile ».

2) Gestion d’alimentation : turbo, gouverneurs et la taxe de latence

Les différences de politique d’alimentation sont l’une des raisons les plus courantes pour lesquelles le même CPU se comporte différemment.

• Sur Linux, vous pouvez être coincé en powersave ou avec un EPP (energy performance preference) conservateur et ne jamais atteindre les fréquences attendues.
• Sur Windows, « Équilibré » booste souvent agressivement sur les systèmes modernes, mais les utilitaires fournisseurs peuvent écraser cela, et le firmware des portables peut brider la puissance soutenue.

La gestion d’alimentation n’est pas seulement « moins de FPS ». Cela peut être du jitter : réveil des cœurs depuis des états C profonds, montée en fréquence tardive, parking/unparking des cœurs, et migration de threads entre cœurs avec caches froids.

Opinion : pour les tests de performance, ne benchmarkez pas sur « équilibré ». Passez en mode performance et supprimez d’abord l’incertitude. Ensuite, réduisez l’alimentation intentionnellement.

3) Résolution des timers et précision du sleep

Les jeux reposent sur le sommeil, l’attente et le pacing. La différence entre un réveil à 1 ms et un réveil à 15,6 ms, c’est la différence entre « fluide » et « pourquoi ça ressemble à de la bouillie ».

Windows a depuis longtemps le concept de modification de la résolution du timer demandé par les applications. Linux a aussi des timers haute résolution, mais le comportement dépend de la config du kernel, du tick rate, et de si quelque chose empêche le CPU d’entrer en idle.

Traduction : deux OS peuvent exécuter le même code et être en désaccord sur ce que « dormez 1 ms » signifie sous charge.

4) Pile graphique et surcharge des pilotes

Sur Windows, la plupart des jeux natifs sont ajustés pour DirectX et le comportement WDDM. Sur Linux, vous pouvez utiliser :

• Vulkan natif
• OpenGL
• Proton/Wine + DXVK (D3D9/10/11 → Vulkan)
• vkd3d-proton (D3D12 → Vulkan)

Chaque couche de traduction a un coût CPU et un comportement de cache. Cela peut être minime, ou brûler plusieurs millisecondes par image dans de mauvais cas (compilation de shader, traduction d’état, bizarreries de synchronisation).

5) Compositeurs, gestionnaires de fenêtres et chemins de present

Sur Windows, DWM est toujours présent, mais le chemin de present varie entre plein écran fenêtré, exclusif et les « optimisations plein écran ». Sur Linux, vous jonglez avec X11 vs Wayland, plus les politiques de votre compositeur (KWin, Mutter, etc.).

La composition peut ajouter de la latence, introduire des buffers supplémentaires, ou forcer une synchronisation à des moments inopportuns. Ou elle peut masquer le tearing et lisser le pacing. L’important : votre environnement de bureau fait partie de la chaîne de rendu.

6) Gestion des interruptions et comportement DPC/softirq

Les interruptions sont de petites urgences. Trop nombreuses, ou mal placées, et votre thread principal perd des tranches de temps juste quand il en a besoin.

• Windows manifeste cela comme des problèmes de latence DPC, souvent liés aux pilotes (réseau, audio, stockage, utilitaires RGB — oui, vraiment).
• Linux le manifeste sous forme de temps softirq, réveils ksoftirqd, problèmes d’affinité IRQ, ou modules kernel défaillants.

Si vos FPS chutent quand vous téléchargez quelque chose, streamez, ou utilisez de l’audio Bluetooth, vous regardez probablement les interruptions et l’ordonnancement des pilotes.

7) Gestion mémoire et reclaim en arrière-plan

Les deux OS ont des systèmes VM sophistiqués. Les deux peuvent vous nuire. Linux peut décider que c’est un bon moment pour reclaimer la mémoire ou compacter les pages. Windows peut décider que c’est un bon moment pour indexer, scanner ou mettre à jour des apps du store. Les détails diffèrent, mais le mode d’échec ressemble au même : des stalls aléatoires de 30–200 ms.

Les jeux qui streament des assets agressivement sont sensibles au comportement du page cache et à l’ordonnancement I/O. Si vous exécutez aussi des navigateurs, launchers et overlays, vous avez construit un petit système distribué — sur une seule machine.

8) Comportement du système de fichiers et de la pile de stockage

Oui, le stockage peut affecter les FPS — en particulier les pics de temps d’image — parce que les jeux modernes streament textures, shaders et géométrie. Windows NTFS vs Linux ext4/btrfs/xfs n’est pas seulement une affaire de débit. Ce sont les politiques de cache, le coût métadonnées, les tâches d’arrière-plan (comme les scrubs btrfs), et la pile pilote NVMe.

Opinion : si vous diagnostiquez du stutter, traitez le stockage comme un suspect de premier plan. Les pics de temps d’image se corrèlent souvent avec des attentes I/O.

9) Fonctionnalités de sécurité et atténuations

Les mitigations kernel pour les vulnérabilités d’exécution spéculative et les fonctionnalités de durcissement peuvent changer le coût des appels système, l’overhead des context switches et le comportement des barrières mémoire.

Parfois l’impact est négligeable. Parfois c’est la différence entre « CPU-bound » et « GPU-bound ». La seule réponse honnête : mesurez sur votre charge.

10) Utilitaires fournisseurs et logiciels « utiles »

Sur Windows : démons OEM d’alimentation, suites audio, enregistreurs d’overlay, contrôleurs RGB, télémétrie carte mère. Sur Linux : extensions de bureau, indexation en arrière-plan, démons d’alimentation, outils laptop-mode, modules kernel hors arbre.

Rien de tout cela n’est intrinsèquement malveillant. Mais chaque service résident est un candidat au jitter.

Une citation à coller sur votre écran : « L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan

Cette phrase est utile opérationnellement parce qu’elle vous force à arrêter de deviner. Mesurez, profilez, et changez une variable à la fois.

Blague #1 : Si vous ne pouvez pas reproduire le stutter, félicitations — vous avez construit un benchmark quantique. L’observer l’a changé.

Mode d’emploi pour un diagnostic rapide

Voici l’ordre de triage que j’utilise quand quelqu’un dit « Linux donne moins de FPS que Windows sur le même CPU » ou « Windows semble saccadé mais Linux est fluide ». Ce n’est pas philosophique. C’est ce qui trouve rapidement le goulot.

Premier point : confirmez quel type de problème vous avez

• Si le FPS moyen est plus bas : suspectez la politique d’alimentation, l’overhead des pilotes, les couches de traduction, ou des limites de fréquence CPU.
• Si les 1 % lows sont pires (pics) : suspectez tâches d’arrière-plan, interruptions, reclaim mémoire, compilation de shaders, attentes I/O, composition, ou problèmes VRR/present.
• Si la latence d’entrée est pire : suspectez buffering, composition, modes vsync, et profondeur des files d’attente dans la pile graphique.

Second point : distinguez CPU vs GPU vs I/O

• GPU-bound : GPU à haute utilisation ; baisser la résolution augmente peu les FPS ; CPU a de la marge.
• CPU-bound : un ou deux cœurs chauds ; baisser la résolution aide peu ; de meilleures fréquences CPU aident beaucoup.
• I/O-stall bound : les pics de temps d’image se corrèlent avec des lectures disque, des page faults, ou des écritures de cache de shaders.

Troisième point : retirez le bruit, puis réintroduisez-le

• Désactivez overlays et enregistreurs.
• Utilisez un profil d’alimentation fixe.
• Essayez un mode de fenêtre différent (exclusif/fenêtré) et les réglages du compositeur.
• Mesurez à nouveau. Ce n’est qu’ensuite que vous commencez à régler des paramètres avancés comme l’affinité IRQ.

Tâches pratiques : commandes, sorties et décisions

Ces tâches sont rédigées comme des runbooks SRE : commande, ce que vous pourriez voir, ce que cela signifie, et ce que vous faites ensuite. La plupart des exemples sont sous Linux parce que c’est introspectable sans outils tiers, mais quelques vérifications Windows comptent aussi.

Task 1: Confirm CPU frequency behavior (Linux)

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|Socket|MHz'
Model name:                           AMD Ryzen 7 5800X3D 8-Core Processor
CPU(s):                               16
Thread(s) per core:                   2
Core(s) per socket:                   8
Socket(s):                            1
CPU MHz:                              3387.000

Ce que cela signifie : CPU MHz est un instantané, pas une vérité. Mais il vous indique si vous êtes coincé à des fréquences basses.

Décision : Si les fréquences semblent basses sous charge, vérifiez le gouverneur/EPP ensuite.

Task 2: Check CPU governor and EPP (Linux)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference
balance_power

Ce que cela signifie : Vous dites au CPU de « sauver de l’énergie », puis vous vous demandez pourquoi il ne sprinte pas.

Décision : Pour les tests, passez en performance (ou réglez EPP sur performance) et relancez le benchmark.

Task 3: Set performance governor temporarily (Linux)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Setting cpu: 4
Setting cpu: 5
Setting cpu: 6
Setting cpu: 7

Ce que cela signifie : Vous réduisez la latence de montée en fréquence et augmentez les fréquences soutenues.

Décision : Si les FPS s’améliorent notablement, la différence d’OS était principalement une question de politique d’alimentation.

Task 4: Verify turbo/boost is active (Linux, Intel example)

cr0x@server:~$ cat /sys/devices/system/cpu/intel_pstate/no_turbo
0

Ce que cela signifie : 0 signifie que le turbo est autorisé.

Décision : Si c’est 1, activez le turbo et retestez. Si vous ne pouvez pas, vérifiez le BIOS ou les limites OEM de puissance.

Task 5: Catch background CPU stealers (Linux)

cr0x@server:~$ top -o %CPU -b -n 1 | head -n 15
top - 10:41:02 up  3:12,  1 user,  load average: 2.31, 1.88, 1.25
Tasks: 312 total,   2 running, 310 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.4 us,  2.1 sy,  0.0 ni, 84.9 id,  0.4 wa,  0.0 hi,  0.2 si,  0.0 st
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
2441 cr0x      20   0 6729348 688144 212000 R  95.0   4.3   2:10.31 game.bin
1882 cr0x      20   0 1492256 102332  52944 S  12.0   0.6   0:20.02 shadercache
1120 root      20   0       0      0      0 S   4.3   0.0   0:11.55 kswapd0

Ce que cela signifie : Si vous voyez kswapd0 ou une activité importante du shader cache pendant le jeu, attendez-vous à des pics.

Décision : Si la pression mémoire est réelle, ajoutez de la RAM ou réduisez les applis en arrière-plan. Si la compilation de shader est en cours, préchauffez les caches ou attendez la fin du premier passage de compilation.

Task 6: Check memory pressure and reclaim (Linux)

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 512348  82344 6021840   0    0    12    55 3210 8120 18  3 79  0  0
 1  0      0 498120  82344 6030100   0    0     0   102 3120 7900 21  4 75  0  0
 3  1      0  88240  82344 6029900   0    0  5120  4200 9800 22000 35  8 49  8  0
 2  1      0  70120  82344 6028800   0    0  6200  3900 10200 24500 32 10 46 12  0
 1  0      0 110220  82344 6029200   0    0   140   180 4100 9000 20  4 76  0  0

Ce que cela signifie : La colonne b (bloqué), plus des pics dans wa (I/O wait) et un fort bi/bo, suggèrent des stalls probablement visibles comme des pics de temps d’image.

Décision : Si vous voyez cela pendant les creux, investiguez le stockage et l’emplacement du shader cache ; assurez-vous que le jeu est sur un SSD rapide ; vérifiez le système de fichiers et l’espace libre.

Task 7: Identify I/O stalls (Linux)

cr0x@server:~$ iostat -xz 1 3
Linux 6.6.8 (server) 	01/10/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.10    0.00    4.80    6.30    0.00   66.80

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz  aqu-sz  %util
nvme0n1         180.0   8200.0     2.0   1.10    5.40    45.6     90.0   6100.0    9.80    67.8    1.22  92.0

Ce que cela signifie : Un %util élevé et un r_await/w_await augmenté pendant un stutter = le stockage fait partie de l’histoire du temps d’image.

Décision : Déplacez le jeu et le shader cache sur le SSD le plus rapide, assurez-vous qu’il n’y a pas de scrubs, d’indexation ou de téléchargements en arrière-plan ; vérifiez le throttling thermique du NVMe.

Task 8: Spot thermal throttling (Linux)

cr0x@server:~$ sensors | egrep 'Tctl|Package|Core|Composite'
Tctl:         +87.5°C
Package id 0:  +91.0°C
Composite:     +78.2°C

Ce que cela signifie : Des températures élevées peuvent déclencher des réductions de fréquence. Certains systèmes thottlent le CPU, certains le GPU, d’autres les deux en silence.

Décision : Si les températures sont proches des points de throttling pendant les benchmarks, corrigez le refroidissement, les courbes de ventilateur, la poussière, le montage ou les limites d’alimentation du portable avant de blâmer l’OS.

Task 9: Confirm GPU driver and render path (Linux)

cr0x@server:~$ glxinfo -B | egrep 'OpenGL vendor|OpenGL renderer|OpenGL version'
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce RTX 4070/PCIe/SSE2
OpenGL version string: 4.6.0 NVIDIA 550.54.14

Ce que cela signifie : Vous êtes bien sur le driver GPU prévu, pas sur un renderer de secours.

Décision : Si vous voyez LLVMpipe ou un GPU incorrect, corrigez l’installation du pilote, les réglages PRIME offload, ou la sélection de périphérique.

Task 10: Check Vulkan device selection (Linux)

cr0x@server:~$ vulkaninfo --summary | egrep 'GPU id|deviceName|driverName|apiVersion' -m 8
GPU id : 0 (NVIDIA GeForce RTX 4070)
driverName = NVIDIA
apiVersion = 1.3.280
GPU id : 1 (AMD Radeon(TM) Graphics)
driverName = RADV
apiVersion = 1.3.275

Ce que cela signifie : Les systèmes multi-GPU peuvent choisir le mauvais device (iGPU vs dGPU), surtout sur les portables.

Décision : Si le jeu tourne sur l’iGPU, forcez le dGPU via des variables d’environnement ou votre méthode de changement graphique, puis retestez.

Task 11: Check compositor / session type (Linux)

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland
cr0x@server:~$ echo $XDG_CURRENT_DESKTOP
GNOME

Ce que cela signifie : Wayland vs X11 peut changer la latence et le comportement VRR selon le compositeur et les pilotes.

Décision : Si vous diagnostiquez un stutter, testez les sessions Wayland et X11 (une à la fois). Prenez des notes.

Task 12: Watch IRQ and softirq load (Linux)

cr0x@server:~$ cat /proc/interrupts | head -n 8
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
  0:         22          0          0          0          0          0          0          0   IO-APIC   2-edge      timer
  1:          0          0          0          0          0          0          0          0   IO-APIC   1-edge      i8042
 24:      88210       1200        980       1100       1050       1001       1122       1088   PCI-MSI 327680-edge      nvme0q0
 32:     190220       3100       2990       3050       3010       2975       3090       3002   PCI-MSI 524288-edge      nvidia

Ce que cela signifie : Un seul CPU recevant la majorité des interruptions peut provoquer du jitter localisé si le thread chaud du jeu atterrit aussi là.

Décision : Si un cœur est un aimant à interruptions, envisagez la configuration d’équilibrage IRQ ou d’éloigner le jeu de ce cœur par pinning (avancé ; testez prudemment).

Task 13: Check per-core load and migration suspicion (Linux)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.6.8 (server) 	01/10/2026 	_x86_64_	(16 CPU)

12:10:01 PM  CPU   %usr  %nice   %sys %iowait  %irq  %soft  %idle
12:10:02 PM  all   24.2    0.0    5.1    1.2    0.0    0.7   68.8
12:10:02 PM    0   12.0    0.0    3.0    0.0    0.0    6.0   79.0
12:10:02 PM    5   78.0    0.0    5.0    0.0    0.0    0.0   17.0
12:10:02 PM    6   65.0    0.0    6.0    0.0    0.0    0.0   29.0

Ce que cela signifie : Un ou deux cœurs chauds sont typiques pour les threads principaux des jeux ; mais si le cœur chaud change constamment, vous payez des coûts de cache-miss et de migration.

Décision : Si la migration se corrèle avec les pics, testez le CPU affinity pinning pour le processus du jeu (prudemment ; ne faites pas de cargo-culting).

Task 14: Check kernel scheduling latency indicators (Linux)

cr0x@server:~$ cat /proc/schedstat | head -n 5
version 15
timestamp 18273648590
cpu0 0 0 0 0 0 0 1234567890 0 0
cpu1 0 0 0 0 0 0 1134567890 0 0
domain0 0 0 0 0 0 0 0 0 0

Ce que cela signifie : Ce fichier est brut, mais c’est un canari : si vous creusez, vous mesurez le scheduling et le runqueue, pas vous ne devinez.

Décision : N’utilisez ceci que si vous êtes prêt à profiler avec perf. Sinon, contentez-vous d’indicateurs de plus haut niveau.

Task 15: Profile CPU hotspots quickly (Linux)

cr0x@server:~$ sudo perf top -g --call-graph fp
Samples: 5K of event 'cycles', 4000 Hz, Event count (approx.): 1200000000
  22.15%  game.bin             [.] UpdateWorld
  14.02%  libnvidia-glcore.so   [.] glDrawElements
   9.88%  dxvk-native.so        [.] dxvk::Presenter::present
   6.41%  [kernel]              [k] schedule

Ce que cela signifie : Vous pouvez voir si vous êtes CPU-bound dans le code du jeu, l’overhead pilote, la couche de traduction, ou si vous passez du temps à scheduler.

Décision : Si l’ordonnanceur kernel est proéminent, réduisez la charge arrière-plan et les interruptions. Si le pilote/traduction domine, testez différentes versions de pilotes ou un chemin API natif.

Task 16: Detect swap usage (Linux)

cr0x@server:~$ swapon --show
NAME      TYPE SIZE USED PRIO
/swapfile file  16G  2G   -2

Ce que cela signifie : L’utilisation du swap pendant une session de jeu peut provoquer des stalls périodiques, surtout sur un stockage lent.

Décision : Si le swap est non négligeable en jouant, réduisez la pression mémoire : fermez des apps, ajoutez de la RAM, ou ajustez la swappiness (et vérifiez que vous ne masquez pas une vraie pénurie de RAM).

Task 17: Find page faults during gameplay (Linux)

cr0x@server:~$ pidof game.bin
2441
cr0x@server:~$ ps -o pid,comm,min_flt,maj_flt,rss,vsz -p 2441
  PID COMMAND   MINFLT  MAJFLT    RSS     VSZ
 2441 game.bin  912345     210 6812200 6820000

Ce que cela signifie : Les défauts majeurs (maj_flt) impliquent des fetchs depuis le disque — souvent visibles comme du stutter si cela arrive en plein action.

Décision : Si les maj_flt augmentent pendant les creux, vérifiez la pression mémoire, le comportement de streaming d’assets, et la performance du stockage.

Task 18: Quick Windows power plan check (Windows)

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

Ce que cela signifie : Vous êtes en Équilibré. Sur certains systèmes c’est acceptable. Sur d’autres c’est une limitation silencieuse.

Décision : Passez à un plan haute performance pour les benchmarks ; si cela règle les FPS, vous avez trouvé un problème de politique, pas un problème de kernel.

Blague #2 : Le logiciel de contrôle RGB a la capacité unique de réduire les FPS tout en augmentant les « frames par seconde » de vos ventilateurs.

Trois mini-histoires d’entreprise du terrain

Mini-histoire 1 : L’incident provoqué par une fausse hypothèse

Un studio avait une suite de benchmarks interne pour un shooter compétitif. La suite s’exécutait chaque nuit sur une poignée de desktops identiques : dual-boot Windows et Linux, mêmes réglages BIOS (en théorie), même branche de pilote GPU (en théorie), même build du jeu.

Un mois, les chiffres Linux commencèrent à dériver vers le bas — lentement. Pas un effondrement catastrophique, juste une érosion progressive des 1 % lows. Les build engineers supposèrent « les drivers Linux sont instables » et commencèrent à ouvrir des bugs contre l’équipe de rendu. L’équipe de rendu fit ce que font les équipes de rendu sous pression : elle ajouta de l’instrumentation. Elle montra des stalls périodiques corrélés au streaming d’assets et aux écritures du shader cache.

Après trop de temps, quelqu’un regarda enfin les logs système. Un tech ops bien intentionné avait activé un scrub de système de fichiers hebdomadaire et une fenêtre de test SMART long sur la partition Linux. Le timing tombait pile pendant les runs de benchmark. Windows n’avait pas le même planning de maintenance. Le CPU était sain ; la latence de stockage n’était pas.

La correction fut douloureusement peu glamour : déplacer les jobs de maintenance hors des heures de benchmark, pinner le shader cache sur un NVMe local rapide, et appliquer un « mode benchmark » via un runbook. Les performances Linux revinrent. L’équipe rendu rouvrit leur semaine. Ops reçut un rappel que « identiques » n’est pas identique quand cron existe.

Mini-histoire 2 : L’optimisation qui a échoué

Un groupe IT d’entreprise voulait rendre des stations Linux « plus réactives » pour un labo de démonstration. Quelqu’un avait lu qu’activer un scaling de fréquence CPU agressif économise de l’énergie « sans impact utilisateur ». Ils déployèrent une config qui poussait l’EPP vers des économies et activait des états idle plus profonds. Les tableaux de bord étaient beaux : moins de watts à l’arrêt, moins de températures, des facilities contentes.

Puis la semaine de démo arriva. Le labo fit tourner un titre VR qui est terriblement sensible au temps d’image. Le FPS moyen n’était pas terrible, mais l’expérience casque avait des hiccups périodiques — exactement le genre qui rend les humains malades et les managers furieux. L’équipe blâma le runtime VR, puis le pilote GPU, puis l’OS. Tout le monde avait tort.

Le profiling montra la latence de montée en fréquence : le CPU ne boostait pas assez vite quand le thread principal du jeu le demandait. Le système était « efficacement » en retard. Ils revinrent à une politique orientée performance pendant les sessions de démo et gardèrent le profil économe pour l’inactivité.

La leçon n’était pas « ne jamais économiser d’énergie ». La leçon : la politique d’alimentation est un contrat de charge de travail. Si votre charge est sensible à la latence, arrêtez de la traiter comme un tableur.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise faisait tourner un client multiplateforme utilisé en formation simulation. Le client était lourd graphiquement, mais le vrai enjeu était la cohérence : les instructeurs avaient besoin d’expériences identiques sur des kiosques Windows et Linux. De petites saccades causaient des divergences visibles dans des scénarios synchronisés.

Ils firent quelque chose radicalement peu cool : ils écrivirent un runbook et l’appliquèrent. Même version de pilote GPU, même cadence de patch OS, mêmes réglages de compositeur, même plan d’alimentation, même liste de services d’arrière-plan. Les benchmarks tournaient depuis un démarrage propre avec le réseau coupé, les logs étaient centralisés, et chaque changement exigeait une comparaison avant/après avec les percentiles de temps d’image.

Quand une mise à jour fournisseur régressa le pacing des images sous Linux, ils l’attrapèrent en un jour parce que les métriques étaient stables et l’environnement contrôlé. Revenir à la version précédente du pilote fut trivial. Ils n’avaient pas eu besoin d’héroïsme, ni de débattre des sensations. Les graphes étaient bruts et clairs.

C’est la vérité ennuyeuse : la plupart des « mystères de performance OS » disparaissent quand vous traitez votre machine de jeu comme un système de production et que vous empêchez les daemons aléatoires d’improviser sur scène.

Erreurs communes : symptôme → cause racine → correction

1) « Linux a des FPS plus bas partout »

Symptôme : FPS moyen en baisse de 10–30 % vs Windows, de manière constante.

Cause racine : Gouverneur CPU/EPP réglé sur économie d’énergie, turbo désactivé, ou limites OEM de portable activées sous Linux.

Correction : Passez le gouverneur en performance pour les tests ; vérifiez le boost ; contrôlez les températures et les limites de puissance ; assurez-vous que le bon driver CPU (intel_pstate/amd_pstate) est actif.

2) « Les FPS sont corrects mais ça saccade toutes les quelques secondes »

Symptôme : FPS moyen plat, mauvais 1 % lows, pics périodiques de temps d’image.

Cause racine : I/O en arrière-plan (shader cache, indexation, services de mise à jour), reclaim mémoire, activité de swap, ou tâches de maintenance planifiées.

Correction : Surveillez iostat/vmstat ; arrêtez les jobs en arrière-plan ; déplacez le jeu/shader cache sur un SSD rapide ; ajoutez de la RAM si vous swappez ; gardez de l’espace libre sain.

3) « Le mode fenêtré sans bord est pire que le plein écran » (ou l’inverse)

Symptôme : Les modes changent drastiquement FPS/latence entre OS.

Cause racine : Chemins de present/compositeur différents : comportement DWM et optimisations plein écran sur Windows ; politiques de compositeur sur Linux (Wayland/X11), gating VRR, buffers supplémentaires.

Correction : Testez le plein écran exclusif, le fenêtré sans bord et la fenêtre normale sur chaque OS. Sous Linux, testez X11 vs Wayland. Choisissez le mode qui donne un pacing stable, pas juste le FPS max.

4) « Linux semble lent avec vsync, mais Windows non »

Symptôme : La latence d’entrée augmente plus que prévu quand vsync est activé.

Cause racine : Différences de buffering par défaut (double vs triple buffer), vsync imposé par le compositeur, ou différences de profondeur de file d’attente dans la pile pilote.

Correction : Ajustez vsync dans le jeu, le limiteur et les modes faible latence. Envisagez le VRR. Évitez d’empiler plusieurs limiteurs (jeu + pilote + compositeur).

5) « Après une mise à jour du pilote, les FPS ont changé »

Symptôme : Changement soudain de performance après mise à jour du pilote GPU ou du kernel.

Cause racine : Invalidation du cache de shaders, nouveau comportement d’ordonnancement, flags par défaut différents, ou régressions.

Correction : Reconstruisez les caches (le stutter du premier lancement est réel), comparez les versions de pilotes, gardez une possibilité de rollback connue, et enregistrez des baselines de benchmark.

6) « L’activité réseau tue les FPS »

Symptôme : Téléchargements/streaming provoquent des creux d’image.

Cause racine : Tempêtes d’interruptions et CPU passé dans la pile réseau ; mauvaise distribution IRQ ; pilotes buggués.

Correction : Vérifiez la distribution IRQ ; assurez-vous de pilotes/firmware NIC modernes ; testez avec le réseau coupé pour confirmer ; envisagez l’équilibrage IRQ et l’affinité CPU seulement après mesure.

7) « C’est pire sur les CPU hybrides »

Symptôme : Jitter ou FPS incohérents sur des CPU avec cœurs performance/efficacité.

Cause racine : Problèmes de placement de threads, migration entre types de cœurs, ou incompatibilité de politique d’alimentation.

Correction : Mettez à jour l’OS/kernel ; assurez le support correct de l’ordonnanceur ; sous Windows, vérifiez Game Mode ; sous Linux, considérez des kernels plus récents et vérifiez le comportement CPUfreq/CPPC.

Listes de contrôle / plan pas à pas

Checklist A: Rendre le benchmark équitable (faites ceci avant de débattre en ligne)

1. Utilisez la même version du jeu, la même carte/scene, mêmes réglages, même résolution, mêmes paramètres d’upscaler.
2. Préchauffez les caches : exécutez la scène une fois, puis faites le benchmark au deuxième passage (ou enregistrez les deux : cold vs warm).
3. Fixez la politique d’alimentation :
   • Windows : activez un plan haute-performance pour les tests.
   • Linux : réglez le gouverneur/EPP sur performance pour les tests.
4. Tuez overlays/enregistreurs et utilitaires fournisseurs « utiles » pour le run de test.
5. Désactivez la maintenance en arrière-plan : mises à jour, indexation, tâches planifiées, scrubs.
6. Capturez des métriques de temps d’image, pas seulement les FPS moyens.

Checklist B: Si Linux affiche moins de FPS, dans l’ordre

1. Vérifiez que vous utilisez le GPU discret et le bon pilote (glxinfo -B, vulkaninfo).
2. Vérifiez le boost CPU et le gouverneur/EPP.
3. Vérifiez les thermiques en charge.
4. Vérifiez si vous êtes CPU-bound (utilisez perf top ou les graphiques CPU/GPU in-game).
5. Si vous utilisez Proton : testez un titre Vulkan natif pour isoler l’overhead de traduction.
6. Testez Wayland vs X11, et les réglages du compositeur qui affectent VRR/vsync.

Checklist C: Si Windows saccade mais Linux est fluide

1. Vérifiez le plan d’alimentation Windows et les utilitaires fournisseurs qui peuvent brider CPU/GPU.
2. Vérifiez les fonctionnalités au niveau pilote qui altèrent l’ordonnancement (par ex. accélération matérielle, modes faible latence).
3. Vérifiez les services en arrière-plan : mécanismes de mise à jour, télémétrie, indexation.
4. Vérifiez le stockage : quelque chose scanne-t-il ou télécharge-t-il pendant que vous jouez ?
5. Validez avec un démarrage propre et des éléments de démarrage minimaux pour isoler.

Checklist D: Quand vous suspectez I/O et shader cache

1. Confirmez que le jeu et le shader cache sont sur un SSD local rapide.
2. Surveillez iostat -xz et vmstat pendant le stutter.
3. Assurez-vous d’un espace libre suffisant ; les SSD se comportent bizarrement pleins.
4. Attendez-vous à ce que la première exécution compile des shaders et saccade. Mesurez le deuxième passage.

FAQ

1) Si le CPU est le même, les FPS ne devraient-ils pas être identiques ?

Non. Le CPU est un composant ; l’OS décide de l’ordonnancement, des états d’alimentation, du comportement des timers, du routage des interruptions, et des interactions de la pile pilote. Tout cela change le comportement effectif du CPU.

2) Pourquoi les moyennes correspondent mais les 1 % lows diffèrent ?

Parce que les pics viennent de contentions et de stalls : I/O en arrière-plan, reclaim mémoire, interruptions, compilation de shaders, et synchronisation de composition. La moyenne masque la douleur.

3) Linux est-il toujours plus lent pour le jeu ?

Non. Les titres Vulkan natifs peuvent très bien tourner. Mais les couches de traduction (DXVK/vkd3d), le comportement des compositeurs, et les différences de pilotes peuvent faire pencher les résultats dans un sens ou l’autre.

4) Le « gouverneur performance » aide-t-il toujours sur Linux ?

Il aide souvent la consistance du temps d’image en réduisant la latence de montée en fréquence. Mais il peut augmenter la chaleur et déclencher du throttling thermique, ce qui annule les gains. Mesurez sous charge soutenue.

5) Plus de RAM réduit-il le stutter ?

Si vous swappez ou forcez un reclaim agressif, oui — dramatiquement. Si vous avez déjà de la marge, plus de RAM ne réparera pas l’overhead pilote ou la latence induite par le compositeur.

6) Pourquoi passer de Wayland à X11 change-t-il les FPS ?

Différents chemins de composition et de présentation. Le support VRR, l’application du vsync, et la gestion des buffers diffèrent selon le compositeur et le pilote, et ces différences se traduisent par des changements de latence et de pacing.

7) Les mitigations de sécurité CPU sont-elles un vrai facteur de FPS ?

Parfois. Elles peuvent augmenter le coût des appels système et des context switches et affecter le comportement des barrières mémoire. L’effet varie selon le CPU, le kernel et la charge de travail. Ne débattez pas — mesurez.

8) Le stockage est-il vraiment lié aux FPS ?

Pour les FPS moyens, généralement non. Pour les pics de temps d’image, absolument — surtout dans les jeux qui streament beaucoup et pendant l’activité du shader cache. Si vous voyez de l’I/O wait pendant les creux, le stockage est impliqué.

9) Dois-je pinner mon jeu sur des cœurs spécifiques ?

Seulement après avoir prouvé un problème d’ordonnancement/interruptions. Le pinning d’affinité peut aider, ou il peut se retourner contre vous en collant le jeu sur un cœur chargé d’interruptions ou en privant des threads workers.

10) Pourquoi Proton bat-il parfois Windows ?

Cela peut arriver quand le chemin Vulkan est plus efficace que le chemin DirectX natif d’un jeu sur Windows, ou quand l’ordonnancement du pilote est plus favorable. C’est spécifique à la charge, pas une loi universelle.

Prochaines étapes qui font vraiment la différence

Si vous voulez des résultats actionnables au lieu d’un débat sans fin « Windows vs Linux », faites ceci :

1. Mesurez les temps d’image, pas seulement les FPS. Suivez moyennes et percentiles. Les pics sont l’ennemi.
2. Verrouillez la politique d’alimentation pour les tests. Mode performance d’abord, puis ajustez vers le bas avec intention.
3. Prouvez CPU-bound vs GPU-bound vs I/O-stall. Utilisez perf, des graphiques d’utilisation, et iostat/vmstat.
4. Contrôlez l’environnement. Même pilotes, même mode de compositeur, mêmes services en arrière-plan. Traitez-le comme une fenêtre de changement en production.
5. Changez une chose à la fois. Si vous changez OS, pilote, kernel, gouverneur, compositeur et réglages du jeu en une fois, vous n’avez pas testé — vous avez lancé les dés.

Windows et Linux ne sont pas que des peaux sur le même CPU. Ce sont des philosophies d’exploitation différentes avec des valeurs par défaut différentes. La différence de FPS est la facture que vous payez pour ces valeurs par défaut. La bonne nouvelle : la plupart des postes de la facture sont détaillés, et vous pouvez contester les charges — si vous venez avec des mesures.