Ce qu’il faut retenir : le 20 août, Hardware Unboxed a repassé la génération d’images d’AMD au banc sur dix jeux, en filmant l’écran à 960 images par seconde et en superposant un affichage du rafraîchissement du moniteur. Le constat est sans appel : le défaut de rythme d’affichage qui accompagne la technologie depuis son lancement en 2024 est toujours présent, aussi bien sur les jeux mis à jour par le pilote que sur ceux qui intègrent nativement la génération FSR 4. Le compteur d’images par seconde, lui, ne voit rien du tout — et c’est précisément le problème. Voici ce qui a été mesuré, pourquoi la moyenne d’IPS est aveugle à ce défaut, le point technique que presque toutes les reprises escamotent, et les réglages qui limitent réellement la casse.

Ce qui a été mesuré, et comment

Le protocole

Le test tourne sur une Radeon RX 9070 XT, avec les pilotes Adrenalin 26.7.1 et un moniteur MSI MAG 321UPX capable de monter à 240 Hz. Dix jeux, répartis en deux groupes de cinq. D’un côté, les titres qui reçoivent la génération d’images par la bascule du pilote, c’est-à-dire l’implémentation FSR 3.1 mise à jour : Cyberpunk 2077, Mafia: The Old Country, Borderlands 4, God of War Ragnarök et Hogwarts Legacy. De l’autre, les titres qui intègrent nativement la série FSR 4 : Crimson Desert, LEGO Batman: Legacy of the Dark Knight, Assassin’s Creed IV Black Flag Remastered, Resident Evil Requiem et Alan Wake 2.

L’intérêt de la méthode tient à un point : un compteur logiciel comme PresentMon mesure quand une image est présentée, pas combien de temps elle reste réellement affichée sur la dalle. Filmer l’écran à 960 images par seconde permet de compter les rafraîchissements du moniteur pendant lesquels chaque image demeure visible. C’est la seule façon d’attraper le défaut décrit ci-dessous.

Le « double tap », en français dans le texte

Le phénomène observé porte le nom de double tap. Une image générée s’affiche très brièvement, puis l’image réelle qui la suit s’attarde plus longtemps. Deux images se succèdent presque collées, puis un vide relatif s’installe avant la suivante. Le compteur additionne bien ses images, la moyenne grimpe, mais le mouvement perçu ne correspond pas à cette moyenne : l’image générée n’a quasiment pas eu le temps d’exister à l’écran, elle n’a donc pas rempli sa fonction.

Jeu	Voie d’intégration	Observation rapportée
Cyberpunk 2077	FSR 3.1 via pilote	Double taps et déchirures autour de 120 ips, sous le plafond de 240 Hz
Borderlands 4	FSR 3.1 via pilote	Stable en marche vers 90 ips, dérive en mouvement rapide à ~98 ips
Mafia: The Old Country	FSR 3.1 via pilote	Résultats contradictoires à ~103 ips, mêmes réglages, même session
God of War Ragnarök	FSR 3.1 via pilote	Double taps nets et déchirures à ~138 ips
Crimson Desert	FSR 4 natif	Perturbations vers 115 ips ; plus fluide sans génération à ~90 ips
LEGO Batman: Legacy of the Dark Knight	FSR 4 natif	20 à 30 images stables, puis une ou deux paires perturbées

Deux résultats méritent d’être soulignés. D’abord Crimson Desert : couper la génération d’images et baisser les réglages pour tomber à environ 90 ips a donné un rendu plus fluide qu’à 115 ips avec génération. Ensuite Mafia: The Old Country, où deux captures faites dans la même session, aux mêmes réglages et à un nombre d’images quasi identique, ont donné l’une une séquence perturbée, l’autre une séquence propre. Cette irrégularité interdit d’accuser l’intégration d’un jeu en particulier — et complique sérieusement le diagnostic.

Pourquoi la moyenne d’images par seconde ne peut pas voir ce défaut

Une moyenne est, par construction, une information qui écrase la dispersion. Un jeu affiché à 120 ips de moyenne peut délivrer 120 images séparées par des intervalles parfaitement réguliers de 8,3 millisecondes — ou alterner des paires collées à 3 millisecondes et des trous à 14 millisecondes. Les deux séquences donnent la même moyenne. Une seule est fluide.

C’est pour cette raison que les mesures sérieuses regardent la distribution des temps par image plutôt que la seule moyenne : le graphe de temps par image, et les centiles bas souvent présentés sous l’étiquette « 1 % low ». Mais même ces indicateurs ont ici une limite, puisqu’ils décrivent le moment où l’image est remise au système, pas la durée pendant laquelle elle reste affichée. Entre les deux se glisse toute la chaîne d’affichage — file d’attente, synchronisation verticale, fréquence variable, balayage de la dalle. C’est exactement dans cet intervalle que se loge le défaut.

La conséquence pratique est inconfortable pour tout le monde, y compris pour nous : un test qui annonce un gain de 80 % d’images par seconde grâce à la génération d’images ne dit rien de la fluidité réellement perçue. Nous appliquons la même prudence quand nous relayons des relevés de performances, comme ceux publiés au lancement de Halo: Campaign Evolved sur trente cartes graphiques : une moyenne se compare, elle ne se ressent pas.

Le point que presque toutes les reprises escamotent : ce sont deux composants distincts

Voilà le cœur du sujet, et il change entièrement la lecture qu’on peut faire de cette affaire.

Chez AMD, la génération d’images ne repose pas sur un bloc unique mais sur deux briques logicielles qui ont des rôles différents et des numéros de version différents.

• La génération d’images par apprentissage automatique, en version 4.0.1, fabrique l’image intermédiaire à partir des vecteurs de mouvement et d’une estimation du flux optique. Elle réclame une carte RDNA 4 de la série RX 9000 ou plus récente — jusqu’à la petite RX 9050 lancée en catimini fin juillet —, DirectX 12 et Windows 11, avec un repli analytique conservé pour les cartes antérieures. C’est elle qui décide de ce qui est affiché.
• La chaîne d’échange de génération d’images, en version 3.1.7, calcule l’intervalle d’affichage visé à partir d’une moyenne glissante, via un fil d’exécution dédié au rythme, pendant qu’un fil de présentation distinct envoie tour à tour images réelles et images générées. C’est elle qui décide quand chaque image est affichée.

Cette séparation a une conséquence directe : le journal des modifications de la version 4.0.1 mentionne le prétraitement des vecteurs de mouvement, la liaison des informations de caméra et la gestion de conditions de concurrence à la fermeture — mais il n’annonce nulle part une correction générale du rythme d’affichage. Autrement dit, améliorer la qualité de l’image intermédiaire et corriger sa date d’affichage sont deux chantiers différents, et seul le premier a visiblement avancé. Dire « AMD n’a pas corrigé son modèle » est donc probablement inexact ; dire « le problème peut se situer dans la chaîne d’affichage, le pilote, la synchronisation ou le système, et personne n’a encore établi lequel » est plus juste, et bien moins spectaculaire.

Les cinq réglages à vérifier avant d’accuser AMD

AMD publie ses propres recommandations de mise en œuvre, et elles sont rarement citées. Elles n’annulent pas le constat de Hardware Unboxed, mais elles décrivent les conditions dans lesquelles la technologie est censée bien se comporter — autant les respecter avant de conclure.

Réglage	Ce que recommande AMD	Pourquoi
Images par seconde avant interpolation	60 minimum ; à éviter sous 30	La génération vise 30 ips et plus, mais le rythme d’affichage optimal n’est visé qu’à partir de 60
Limiteur d’images	Fortement recommandé	Stabilise l’intervalle cible calculé par la moyenne glissante
Synchronisation verticale sous fréquence variable	Désactivée si les temps par image fluctuent, activée s’ils sont stables	Le mauvais choix produit déchirures ou saccades selon le cas
Surcouches et enregistreurs	Éviter tout ce qui intercepte DXGI	Un bon rythme suppose un accès non entravé à la chaîne d’échange
Plafond de la dalle	Rester sous la fréquence maximale du moniteur	Une sortie qui touche le plafond fausse la présentation des images

Un cas rappelle toutefois que ces conditions ne suffisent pas toujours : dans God of War Ragnarök, les double taps et les déchirures apparaissent à environ 138 ips en sortie, alors que la fréquence avant interpolation dépassait largement le seuil de 60 recommandé par AMD. Respecter la consigne ne garantit pas un affichage régulier sur toutes les implémentations.

Ce que cette étude ne prouve pas

Il faut être précis sur la portée de ces résultats, d’autant que plusieurs reprises les ont durcis.

Il s’agit d’un test qualitatif mené dans un seul environnement : une carte, un pilote, un moniteur, un ensemble de réglages. Rien n’autorise à généraliser à toutes les Radeon, tous les écrans à fréquence variable ou toutes les configurations. La vidéo ne fournit pas de tableau de mesures chiffrées sur les dix titres, et les images à 960 ips montrent le symptôme sans identifier la couche responsable — système, synchronisation verticale, fréquence variable, file d’attente ou chaîne d’échange. La reproductibilité fluctuante observée sur Mafia renforce ce point.

Le testeur rapporte par ailleurs avoir trouvé le rythme d’affichage de la génération d’images de NVIDIA plus régulier dans les mêmes jeux. C’est une observation, et elle mérite d’être citée telle quelle — mais elle n’est pas accompagnée d’une comparaison chiffrée à conditions identiques sur les dix titres. En tirer une recommandation d’achat serait aller nettement plus loin que ce que la méthode permet. Enfin, AMD n’a ni reconnu officiellement ce défaut ni annoncé de calendrier de correction : nous en sommes au stade du signalement documenté, pas du bogue confirmé.

Pourquoi ça compte pour la suite

Le calendrier rend l’affaire plus intéressante qu’un simple constat technique. Des références à une génération multi-images allant jusqu’à 8X ont été repérées dans les pilotes Radeon cet été. Or l’arithmétique du rythme d’affichage est impitoyable : si une seule image générée sur trois peine à être présentée au bon moment, en insérer sept entre deux images réelles ne dilue pas le problème, il le multiplie. Une technologie multi-images n’a de sens que si la couche qui cadence l’affichage est irréprochable.

C’est aussi une bonne raison de surveiller les prochains journaux de modifications d’AMD : si une correction de rythme d’affichage y apparaît explicitement, elle indiquera dans quelle couche se logeait le défaut. Les pilotes bougent vite en ce moment, entre les versions Adrenalin 26.7.1 et GeForce 610.88 de fin juillet et les corrections qui accompagnent chaque sortie majeure.

Reste la question que ce test pose sans la formuler : dans un marché où les cartes graphiques d’entrée de gamme se raréfient et renchérissent, la génération d’images est devenue l’argument commercial qui permet d’afficher de gros chiffres sans silicium supplémentaire. Il est d’autant plus important que ces chiffres correspondent à quelque chose de perceptible. Ceux qui n’ont pas de carte du tout, eux, regardent désormais ailleurs, du côté du jeu en nuage, dont la latence a nettement progressé — où le rythme d’affichage est, ironie de l’histoire, exactement le même sujet de préoccupation.

Questions fréquentes

Dois-je désactiver la génération d’images FSR ?

Pas systématiquement. La bonne méthode consiste à comparer par vous-même, sur votre écran, entre la technologie activée et désactivée à réglages graphiques légèrement abaissés pour retrouver une fréquence native correcte. Le test rapporte au moins un cas — Crimson Desert — où 90 images par seconde natives ont paru plus fluides que 115 avec génération. Votre perception du phénomène compte autant que la mesure.

Comment repérer ce défaut chez moi ?

À l’œil nu, il se manifeste par une sensation de saccade légère et régulière alors que le compteur affiche une valeur élevée, souvent plus visible en mouvement latéral rapide. Un graphe de temps par image aide, mais ne montrera pas tout, puisque le défaut se situe en aval de la présentation. Filmer l’écran au ralenti avec un téléphone récent donne, curieusement, une indication plus fiable.

Les cartes GeForce sont-elles concernées ?

Le test ne portait que sur la technologie d’AMD. Le testeur indique avoir trouvé le rythme d’affichage de la solution NVIDIA plus régulier sur son échantillon, sans mesure chiffrée à conditions identiques permettant d’en faire une conclusion générale. Le principe de l’insertion d’images générées, lui, expose toutes les implémentations à ce type de difficulté.

Une mise à jour de pilote peut-elle corriger le problème ?

Peut-être, mais rien ne le garantit. Puisque la couche responsable n’a pas été identifiée, la correction peut relever du pilote, de la chaîne d’échange, de l’intégration dans le jeu, voire de la combinaison avec les réglages de synchronisation. C’est précisément pour cette raison qu’il faut lire les journaux de modifications à venir plutôt que d’attendre une correction automatique.

Ce défaut ajoute-t-il de la latence ?

Le rythme d’affichage et la latence sont deux sujets distincts. Toute génération d’images ajoute mécaniquement un peu de latence, puisqu’il faut disposer de l’image suivante pour fabriquer l’intermédiaire. Le défaut décrit ici concerne la régularité de l’affichage, c’est-à-dire la fluidité perçue, et non le délai entre votre geste et sa prise en compte. Les deux peuvent se cumuler et donner l’impression désagréable d’un jeu « rapide sur le papier, mou à la manette ».

Sources

• VideoCardz — « AMD still hasn’t fixed FSR Frame Generation’s frame pacing problem » (21 août 2026)
• OC3D — « AMD FSR Frame Generation still has issues » (20 août 2026)
• XenoSpectrum — analyse détaillée du protocole et des dix jeux testés (21 août 2026)
• AMD GPUOpen — documentation de la chaîne d’échange de génération d’images 3.1.7 (fil de cadencement, moyenne glissante, recommandations de synchronisation)