Frame generation : comment ça marche vraiment

Cinq images générées pour une seule image réellement calculée par le moteur de jeu. C'est ce que NVIDIA revendique pour le mode 6X de DLSS 4.5, annoncé le 6 janvier 2026. Ce chiffre ne dit rien du mécanisme qui le rend possible, ni des quatre autres façons de faire à peu près la même chose chez AMD et Intel. Cinq implémentations, trois constructeurs, et des prérequis qui ne se recoupent jamais d'une marque à l'autre.

Réponse directe : la frame generation fait calculer par un réseau de neurones une image intermédiaire entre deux images réellement rendues, à partir des vecteurs de mouvement et de la profondeur. NVIDIA (DLSS Frame Generation, Smooth Motion), AMD (FSR Frame Generation, AFMF) et Intel (XeSS-FG) l'implémentent différemment, avec des cartes, des entrées techniques et des seuils de framerate propres à chaque marque, jamais interchangeables.

Comment un GPU invente-t-il une image qu'il n'a jamais calculée ?#

Les guides grand public s'arrêtent presque tous au même endroit : « l'IA génère des images intermédiaires ». Exact, mais creux. Les guides développeur de NVIDIA, AMD et Intel, eux, documentent le mécanisme jusqu'au niveau du buffer attendu en entrée, et aucun des comparatifs qui trustent la première page de résultats ne les cite.

Chez NVIDIA, le réseau DLSS Frame Generation prend quatre entrées : l'image courante, l'image précédente, un champ de flux optique et les données du moteur (vecteurs de mouvement et profondeur), selon la documentation officielle. Ce champ de flux optique capture ce que les vecteurs de mouvement du moteur ne contiennent pas : particules, reflets, ombres, éclairage. Sur DLSS 3, il sortait d'un accélérateur matériel propre à l'architecture Ada Lovelace ; depuis DLSS 4, NVIDIA le fait produire par un modèle IA, et le flux optique matériel n'est plus utilisé. Le guide de programmation DLSS-G, publié sur le dépôt GitHub NVIDIA-RTX/Streamline, précise que trois ressources doivent transiter par l'application : le backbuffer, la profondeur et un champ de vecteurs de mouvement dense, incluant le mouvement de la caméra et celui des objets. Autre exigence documentée, plus surprenante : l'intégration de Reflex est obligatoire, sans option, écrite noir sur blanc dans la section consacrée aux prérequis.

Côté AMD, la logique change. FSR Frame Generation s'appuie sur des algorithmes d'apprentissage automatique entraînés sur des GPU Instinct, qui prédisent le mouvement et l'apparence de chaque pixel, puis les mélangent à une reprojection par vecteurs de mouvement pour fabriquer l'image intercalaire, précise GPUOpen. Le manuel technique de FidelityFX Optical Flow descend plus loin dans le détail : l'algorithme travaille par blocs de 8x8 pixels, répète sept fois une séquence de trois passes (recherche, filtrage, upscaling), puis nettoie les valeurs aberrantes avec un filtre médian 3x3. Le genre de détail qu'aucun article marketing ne mentionne, et qui explique pourquoi deux implémentations « IA » ne se comportent pas pareil sur un écran chargé de particules.

Intel, enfin, traite la frame generation comme une suite de passes de compute shader exécutée juste avant l'événement de présentation, d'après le guide développeur du dépôt intel/xess. XeSS-FG réclame trois entrées à chaque image (vecteurs de mouvement, tampon de profondeur, constantes d'image), et surtout une dépendance dure : sans XeLL intégré, la swap chain proxy de XeSS-FG échoue purement et simplement à s'initialiser. Aucune des trois marques ne documente son point de rupture aussi précisément que dans son propre guide, ce qui en dit long sur la valeur de lire la doc plutôt que le communiqué.

Le tableau des prérequis, cinq implémentations, cinq jeux de règles#

Voilà le tableau que la première page de résultats ne donne jamais en entier : les cinq implémentations, côte à côte, avec leur matériel, leurs entrées et le niveau de confiance de chaque ligne.

Implémentation	Constructeur	Matériel requis	Entrées techniques exigées	Confiance et source
DLSS Frame Generation	NVIDIA	RTX 40 et RTX 50 (Ada Lovelace et Blackwell)	Backbuffer, profondeur, vecteurs de mouvement denses ; intégration NVIDIA Reflex obligatoire	HAUTE, NVIDIA (GeForce News, Streamline)
Smooth Motion	NVIDIA, pilote	RTX 50 au lancement, étendu aux RTX 40 le 18 août 2025	DirectX 11, DirectX 12 ou Vulkan ; réservé aux jeux sans DLSS Frame Generation natif	HAUTE, NVIDIA (GeForce News)
FSR Frame Generation	AMD	Version ML : Radeon RX 9000 et au-dessus (RDNA 4). Repli analytique : GPU Shader Model 6.2 ou plus, Windows 11 dans les deux cas	Vecteurs de mouvement, profondeur, position et orientation de la caméra	HAUTE, AMD (GPUOpen)
AFMF	AMD, pilote	RX 6400 à RX 7900 XTX au moment de l'extension RDNA 2 (2023), jeux DX11 et DX12	Non documenté en verbatim AMD, page officielle inaccessible à la rédaction de cet article	MOYENNE, source secondaire (HotHardware, 2023)
XeSS-FG	Intel	Pilote 32.0.101.7029 ou plus récent ; Arc Alchemist, Arc Battlemage, iGPU Core Ultra ; ou tout GPU non Intel avec Shader Model 6.4	Vecteurs de mouvement, tampon de profondeur, constantes d'image à chaque image ; XeLL obligatoire	HAUTE, Intel (guide développeur XeSS-FG)

Une précision qui compte pour la ligne AFMF : la page officielle AMD sur le sujet ne m'a pas été accessible malgré plusieurs tentatives. Les chiffres qui circulent (GPU couverts, seuils de framerate) viennent d'une couverture presse de 2023, relayée par HotHardware, jamais confirmée directement par une page AMD que j'ai pu lire moi-même. Traitez cette ligne comme une indication datée, pas comme une fiche produit.

Smooth Motion mérite aussi qu'on s'y arrête, parce que la confusion avec DLSS Frame Generation est fréquente. Smooth Motion est un modèle IA au niveau du pilote qui infère une image entre deux images rendues, pour les jeux qui n'ont pas de support natif de DLSS Frame Generation, précise NVIDIA. Ce n'est ni le même mécanisme ni le même public : DLSS Frame Generation s'intègre au moteur du jeu, Smooth Motion se pose au-dessus, sans que le studio ait rien codé.

Frame generation et upscaling, deux technologies qu'on confond trop souvent#

C'est l'erreur la plus fréquente dans les articles sur le sujet, et elle mérite d'être tranchée avant d'aller plus loin : la frame generation et l'upscaling ne sont pas la même brique. L'upscaling reconstruit une image à partir d'un rendu en résolution réduite. La frame generation, elle, fabrique une image entièrement nouvelle entre deux images déjà rendues en pleine résolution. Les deux peuvent tourner ensemble, mais elles s'activent, se désactivent et se documentent séparément.

Chez Intel, le dépôt xess le confirme noir sur blanc : XeSS-SR (l'upscaling) et XeLL peuvent s'activer indépendamment l'un de l'autre, alors que XeSS-FG, lui, réclame XeLL comme prérequis obligatoire. Chez AMD, la frame generation reste compatible avec des upscalers tiers, du moment que les vecteurs de mouvement et la profondeur sont fournis à l'API dans le bon format. Deux briques, deux logiques distinctes. Notre comparatif FSR, DLSS et XeSS traite l'upscaling en détail, versions et gains de FPS à l'appui ; il ne parle presque pas de frame generation, et ce n'est pas un oubli, c'est un sujet à part entière. Le guide plus large sur ce qu'est DLSS et comment l'activer détaille d'ailleurs les cinq briques distinctes de la suite NVIDIA, frame generation comprise.

DLSS 4.5, le mode 6X et le Dynamic MFG : ce que le comparatif générique rate#

Trois dates suffisent à périmer la plupart des articles encore en tête des résultats. Le 6 janvier 2026, NVIDIA annonce DLSS 4.5 : le mode 6X génère cinq images supplémentaires par image rendue traditionnellement, contre trois en Multi Frame Generation classique, et le Dynamic MFG ajuste ce multiplicateur automatiquement. Les deux fonctionnalités sont annoncées pour le printemps, réservées aux RTX 50. Le 10 décembre 2025, AMD sort FSR Redstone, qui fait passer FSR Frame Generation d'une interpolation analytique à un modèle ML, réservé aux Radeon RX 9000 (architecture RDNA 4), la version analytique restant disponible en repli sur RDNA 3.5 et antérieur. Le 18 août 2025, enfin, NVIDIA étend Smooth Motion aux RTX 40, qui n'y avaient pas droit au lancement de la fonctionnalité, jusque-là réservée aux seules RTX 50.

Un article qui cite encore Smooth Motion comme exclusive aux RTX 50, ou FSR Frame Generation comme purement analytique, décrit un état du marché qui n'existe plus. Notre actualité sur DLSS 4.5, le Transformer 2e génération et le Multi Frame Generation 6X détaille cette annonce dans son ensemble ; cet article-ci explique le mécanisme qui la sous-tend, pas l'inverse.

J'ai passé une soirée entière à lire les trois guides développeur d'affilée, celui de NVIDIA, celui d'AMD et celui d'Intel, pour écrire cette section. Résultat : trois vocabulaires différents pour décrire à peu près le même problème, et aucune passerelle entre les trois. Si un développeur me dit un jour qu'intégrer les trois technologies dans un même moteur est simple, je ne le croirai pas.

Ce mécanisme rejoint deux autres entrées déjà publiées dans cette même série lexicale : le rollback netcode, qui prédit lui aussi avant de corriger si besoin, et le duo ray tracing et path tracing, qui pose le problème de calcul brut que la frame generation contourne par l'interpolation plutôt que par le rendu.

Quand activer la frame generation, et quand s'en abstenir ?#

C'est la question que le SERP pose sans jamais y répondre avec un chiffre sourcé, et il faut être honnête avant d'aller plus loin : NVIDIA ne publie aucun seuil de framerate minimal avant d'activer DLSS Frame Generation. J'ai cherché dans l'ensemble du guide Streamline et dans les annonces GeForce News, rien. NVIDIA documente des cas où il faut couper la fonctionnalité, pas un plancher de fps en dessous duquel l'activer ne sert à rien.

AMD et Intel, eux, chiffrent. GPUOpen fixe le seuil de FSR Frame Generation à un minimum de 60 fps avant interpolation pour un fonctionnement optimal, et qualifie le passage sous 30 fps avant interpolation de situation à éviter absolument. Intel recommande 40 fps minimum et 60 fps pour la meilleure expérience de latence, mesurés en entrée de la chaîne (XeSS-SR ou natif). Deux seuils, deux constructeurs, aucune règle commune que je puisse vous donner sans l'attribuer précisément à l'un des deux.

Ce que NVIDIA documente en revanche, ce sont les cas de dégradation à éviter. Couper DLSS Frame Generation dans les menus plein écran, en pause, et dès qu'un élément d'interface couvre la majorité de l'écran : c'est écrit dans le guide Streamline. Un cas de figure précis, celui d'un gros multiplicateur combiné à un V-Sync activé sur un écran à faible taux de rafraîchissement, augmente significativement la latence d'entrée, parce que les images générées s'accumulent plus vite que l'écran ne peut les afficher. Ce type d'interaction entre synchronisation d'affichage et technologie logicielle, j'en avais déjà détaillé une autre version dans mon dossier sur le VRR, plateforme par plateforme. Intel donne une consigne similaire pour sa propre fonctionnalité : désactiver XeSS-FG dans un menu plein écran ou en pause.

Sur le coût réel en latence, je ne vous donnerai aucun chiffre en millisecondes qui tienne debout. Une mesure de 2026 relevée par un site russe, GameGPU, compare, sur Cyberpunk 2077, un rendu natif à 36 fps sans upscaling à des configurations qui cumulent upscaling, Reflex et frame generation : ça ne mesure pas le coût de la frame generation seule, ça mesure l'écart entre rouler à vide et rouler à plein régime, ce qui n'a rien à voir. Aucune mesure indépendante 2026 à variables isolées n'existe à ma connaissance. Si vous voulez comprendre où se mesure réellement la latence d'un système, chaîne complète, mon article sur l'input lag détaille la méthode ; je ne la répète pas ici.

Sur ce que fait exactement l'input du joueur pendant qu'une image générée s'affiche, je reste prudent : le principe même de l'interpolation laisse penser qu'une image générée ne porte aucune nouvelle information de jeu, seulement une extrapolation visuelle entre deux états réels. Mais c'est ma lecture du mécanisme documenté, pas une citation : aucun des trois constructeurs ne l'écrit en ces termes dans sa documentation.

Trois constructeurs, cinq implémentations, une chose en commun malgré tout : chacun documente précisément où sa propre technologie ne doit pas tourner. C'est probablement le renseignement le plus utile de cet article, et il ne tient pas dans un chiffre.

FAQ#

Quelle est la différence entre DLSS Frame Generation et Multi Frame Generation ?#

Sur RTX 40 comme sur RTX 50, DLSS Frame Generation intercale une image entre deux images rendues. Multi Frame Generation, réservée aux RTX 50, va plus loin : réglé à trois images à générer, le paramètre numFramesToGenerate produit un multiplicateur de 4x, soit quatre images présentées pour une seule calculée. Le mode 6X de DLSS 4.5 pousse ce total à cinq images générées par image rendue.

Existe-t-il un framerate minimum avant d'activer la frame generation ?#

Cela dépend du constructeur, et NVIDIA ne publie aucun chiffre sur ce point précis pour DLSS Frame Generation. AMD recommande un minimum de 60 fps avant interpolation pour FSR Frame Generation, et déconseille absolument de l'activer sous 30 fps. Intel fixe 40 fps comme plancher et 60 fps comme cible recommandée pour XeSS-FG. Aucune de ces valeurs ne se transpose d'un constructeur à l'autre.

La frame generation et l'upscaling, c'est la même chose ?#

Non. L'upscaling reconstruit une image depuis une résolution réduite, la frame generation fabrique une image entièrement nouvelle entre deux images déjà rendues en pleine résolution. Intel permet d'activer XeSS-SR et XeLL indépendamment de XeSS-FG, ce qui illustre bien la séparation des deux briques. Notre comparatif dédié à l'upscaling traite l'autre sujet en détail.

AFMF fonctionne-t-il comme FSR Frame Generation ?#

Non, ce sont deux fonctionnalités distinctes chez AMD. FSR Frame Generation s'intègre au jeu via une API documentée par GPUOpen. AFMF opère au niveau du pilote, sans intégration du studio, mais sa documentation officielle sur le site AMD n'a pas pu être consultée directement pour cet article : les informations disponibles viennent d'une source secondaire de 2023, à prendre avec cette réserve.

Pourquoi faut-il désactiver la frame generation dans les menus ?#

NVIDIA et Intel documentent tous les deux la même recommandation pour leur propre technologie : couper la frame generation dans un menu plein écran ou en pause. NVIDIA précise aussi le cas d'un élément d'interface qui couvre la majorité de l'écran. Dans ces situations, l'image générée par interpolation dégrade le rendu de l'interface plutôt que de l'améliorer.