Sommaire
Raytracing / Path tracing
Il doit être difficile en 2026 de ne pas avoir entendu les termes Raytracing et Path tracing. Mais concrètement, qu’est-ce que c’est et en quoi cela affecte les jeux vidéos ?
Pour en parler, il faut déjà revenir aux fondamentaux, c’est-à-dire la Rastérisation.
En modélisation 3D on a besoin d’afficher en deux dimensions (nos écrans) des objets en 3 dimensions. Étant loin d’être un expert de ces sujets, je dirais au doigt mouillé que ça doit remonter aux premiers rendus 3D.
Dans le contexte de la rastérisation, les objets à l’écran sont créés à partir d’un maillage virtuel de triangle ou de polygones (un mesh). Les coins de nos triangles sont appelés des vertices, et contiennent un paquet d’informations, comme leur position dans l’espace, ou bien leur couleur ou encore des données dite de « normale » qui permettent de déterminer la façon dont les faces d’un objet se présentent.
L’ordinateur convertit ensuite les triangles et les données des vertex en pixels affichés en 2D.
C’est la base de la rastérisation, on peut ensuite chaîner d’autres modifications sur nos pixels (des shaders : des programmes spécialisés qui fonctionnent en parallèles sur un GPU) pour modifier le rendu. C’est à cette étape que l’on fera de la magie noire pour simuler des effets de lumière, de réfraction, de réflexion, d’occlusion et j’en passe.
Pour les ombres il y a différentes techniques, la plus commune est la carte d’ombrage, qui permet de pré-calculer ou de calculer en temps réel ce qui est dans l’ombre (et doit donc être assombri) et ce qui ne l’est pas. Mais ces ombres sont dites « dures », pour des ombres diffuses (dites « soft ») il faut procéder un peu autrement.
On s’en sort en pratique fort bien, et d’autres techniques viennent compléter le tableau comme :
- les lightmaps,
- l’occlusion ambiante (SSAO, GTAO, etc.),
- les sondes de réflexions,
- les réflexions planaires qui — bien que gourmandes — donnent des réflexions claires comme le cristal en rendant la scène deux fois,
- le SSR qui tente de reconstruire des réflexions à partir des informations déjà affichées,
- les systèmes d’illuminations globales (SDFGI, Lumen)
- les systèmes d’antialiasing
- et une véritable myriade de joyeusetés toutes plus complexes et délicates les unes que les autres.
Source : OpenMW
Avec pour chaque technique des limites et inconvénients avec lesquels le développeur devra composer pour atteindre son objectif.
Ces liens donnent des informations pertinentes et compréhensible sur ces sujets :
Aussi, ce journal de small_duck est particulièrement intéressant et facile à lire, en plus de présenter l’évolution des techniques de rendue antérieures à la rastérisation.
Et ce sera fait pour chaque pixel de l’écran. Pour un rendu en 4K on a 8 millions de pixels, et on cible de 30 à 90 images par seconde en moyenne. Mais les GPU modernes sont très forts à ce jeu-là.
Bon très bien, et le raytracing me direz-vous ? Attention à ne pas confondre avec le Raycasting, dont nous parlait jtremesay dans son journal en 2022.
On l’a vu avec la rastérisation, on procède de la manière qui nous a parue la plus efficace avec les moyens donnés. Mais si on visait des rendus plus réalistes, et par réaliste j’entends physiquement réaliste, il y a d’autres approches.
Dans le domaine de l’illumination globale citée plus haut, le raytracing (« lancer de rayon »), permet de remplacer quantité d’effets simulés par les autres techniques et ce avec une qualité et une fidélité supérieure. Le ray tracing est conçu dans les années 60 par Robert Goldstein, Roger Nagel de MAGi et Arthur Appel d’IBM.
Turner Whitted introduit le raytracing récursif dans un papier en 1980. Il décrit comment l’information de rendu est stockée dans un arbre, se propageant vers les surfaces puis vers les sources lumineuses, permettant de simuler fidèlement réflexions, ombres et réfractions.
Cette technique de rendu procède différemment de la rastérisation. Il faut imaginer que depuis chaque pixel de l’écran, un rayon va être envoyé dans le monde 3D, et quand ce rayon va toucher une surface, on va récupérer sa couleur. On pourra ensuite en fonction des données de la surface, lancer d’autres rayons, qui iront toucher d’autres surface et ainsi affiner la couleur de notre pixel.
C’est très similaire dans l’idée à l’ancienne théorie de la vision émissive.
Source : Path tracing sur Wikipedia
De ce fait, on calcule par un seul moyen, non seulement les couleurs des surfaces, mais aussi leur émission, leurs réflexions, leur ombrage et ce en tenant compte d’objets en dehors de l’espace visible à l’écran. C’est un moyen extrêmement puissant de rendre un monde en 3D, et ce n’est ainsi pas pour rien qu’il est utilisé pour le rendu des films d’animation par Pixar et Dreamworks dès les années 80 (avec une approche hybride) et plus généralement dans les années 2000.
Car il faut dire, et je pense qu’on peut s’en douter, que le raytracing est horriblement peu performant. Le lancer de rayon à lui seul est un goulot d’étranglement monstrueux.
Mais pourquoi s’arrêter en si bon chemin ? Le Path tracing, introduit par James Kajiya en 1986, plus moderne, est une forme de raytracing. À chaque rebond, au lieu de lancer plusieurs rayons déterministes, on tire une seule direction aléatoire selon une distribution statistique. Cela permet de simuler fidèlement la lumière indirecte, les caustiques, les surfaces translucides, au prix d’un bruit important.
D’apparence moins performante et complexe, cette méthode permet toutefois un résultat plus granulaire, en changeant le nombre de rayons initiaux. Le pathtracing doit accumuler suffisamment d’échantillons aléatoires pour que la moyenne converge vers une image propre. Avec peu d’échantillons, l’image est bruitée. Pour réduire ce bruit il faut soit plus d’échantillons (plus lent), soit un bon débruiteur.
Certaines parties d’une scène comme les miroirs ou les surfaces en verre nécessiteront plus de rayons pour rester cohérentes, se rapprochant de la version raytracing plus classique.
Source: nVidia
Dans le domaine du jeu vidéo, il a ainsi fallu attendre jusqu’à récemment pour que cette technique devienne viable pour du rendu temps réel. C’est nVidia qui a ouvert le bal en 2018 avec une conférence pour le lancement de leurs cartes RTX. AMD suivra avec les RX6000 et surprenamment, Intel avec les Arc.
Cette démo de THREE.js tourne dans le navigateur et affiche une boite de Cornell avec du Path Tracing.
Ces nouvelles cartes utilisent des unités matérielles dédiées au lancer de rayon, opération autrefois purement logicielle. Mais ça ne suffit pas à atteindre la vitesse suffisante pour une expérience fluide.
Ces cartes embarquent donc également une autre technologie, au moins aussi importante que le raytracing. Le DLSS.
Histoire de se faire une idée rapidement, ce mod de DOOM 2 supporte le raytracing et ça change vraiment, avec un rendu atmosphérique !
Source : Le mod Doom 2: RAY TRACED sur moddb par shirokii
DLSS, FSR, XeSS, Reflex, Anti-Lag
nVidia présente donc en février 2019 le Deep Learning Super Sampling (DLSS) ou Super Échantillonnage en Apprentissage Profond. C’est une technologie de redimensionnement visant à produire une image plus grande à partir de la sortie du pipeline graphique.
Le défi étant de fabriquer ou de retrouver des détails à partir de pas grand-chose. Le DLSS utilise un réseau de neurones pour produire un résultat plutôt convaincant, surtout à mesure que les versions du DLSS se sont enchaînées. À tel point que le DLSS affiche parfois un meilleur rendu que le rendu natif.
En effet, si le but premier du DLSS et des autres technologies concurrentes est de réduire la résolution de rendu pour gagner en performance, le traitement du réseau de neurones peut être si bon qu’il parvient à reconstituer des détails plus fins que ce que produit le rendu natif.
Pour cela, il se base sur les images affichées, mais également sur des données fournies par le moteur, comme le vecteur de mouvement de l’image.
Il permet également de produire un rendu qui a virtuellement une résolution supérieure au natif qui est ensuite réduit à la résolution native. À la manière d’un Oversampling, mais sans le surcoût occasionné par le fait de rendre en 2 ou 4 fois plus grand.
Le DLSS est une technologie propriété de nVidia, qui utilise (sauf pour les premières versions) des éléments matériels pour fonctionner, des accélérateurs d’IA dédiés appelés Tensor Cores.
Les cœurs Tensor et autres accélérateurs IA peuvent entre autre utiliser des données de type FP16, INT8, INT4 et INT1, retenez-les bien, ça sera important.
Il n’a pas fallu longtemps avant qu’AMD ne se lance également sur le sujet avec son FidelityFX Super Resolution. Avec une approche différente, leurs cartes Radeon n’embarquant pas d’unités dédiées contrairement aux RTX de nVidia.
La première version du FSR est plus proche d’un shader d’upscalling comme ceux utilisés dans l’émulation retro que de ce que fait le DLSS.
Mais il a le mérite d’exister et de s’exécuter sur pratiquement n’importe quoi. Il a aussi le bon goût d’être libre. Il faudra attendre la version 2 pour voir quelque chose de plus intéressant, toujours agnostique du matériel utilisé et libre, et utilisant cette fois les vecteurs de mouvement également.
Cette fois-ci, si on est pas à la hauteur du DLSS on a quand même un gain de qualité par rapport à une résolution inférieure. Aux prix d’une image plus instable. Le FSR 3 (toujours libre et agnostique) améliorera un peu cette situation, mais sans régler tous les problèmes.
Sources : Notebook Check et Digital Foundry
Mais, car il y a un mais. Mais, donc, ces technologies ont un coût. En effet, même en faisant le rendu à une résolution plus faible que le natif et donc plus rapidement, il n’en reste pas moins que la mise à l’échelle prend du temps. Accélérateurs dédiés ou non. Dans un cas où on essayait de ramener des performances perdues lors de l’activation du Raytracing, on se retrouve à augmenter la latence.
Mais, car il y a de nouveau un mais, à chaque nouveau problème technologique, une solution (technologique elle aussi) existe ! nVidia se fend alors de la technologie Reflex, là ou AMD saupoudre son Anti-Lag et distille son Anti-Lag +. Ces solutions logicielles, propriétaires, fonctionnent uniquement sous Windows et à peu près de la même manière. Apparemment de base, le CPU peut préparer plus d’images que le GPU ne peut en afficher, remplissant alors un tampon ou une liste d’attente de rendu.
Plus il y a d’images dans la liste, plus la latence augmente, l’idée est donc de mieux synchroniser le rendu CPU et GPU, pour minimiser la taille de cette liste et donc la latence.
Suffisant ? Je ne sais pas.
Dans le même temps, Intel, qui se tâtait à se relancer sur le marché des GPU dédiés, se fend d’une première gamme de cartes graphiques, les Arc. Les cartes sont en dessous matériellement et logiciellement par rapport à leurs concurrentes, mais parviennent tout de même à faire tourner la plupart des jeux du moment. Si les pilotes ont des soucis de jeunesse, la prise en charge de Linux est de base très bonne et libre.
De manière générale, ces dernières années, le pilote libre des cartes Intel et AMD sous Linux est très bon et celui de nVidia s’améliore et s’ouvre un peu plus très peu mais reste basé sur un socle qui bien que performant est propriétaire.
Bref, Intel à la sortie de ses premières cartes (depuis un bail) les lance avec la gestion du raytracing et un équivalent aux DLSS et FSR : le XeSS. Il est plus proche du DLSS que du FSR, mais est agnostique du matériel comme le FSR. Il n’utilise d’accélérateur IA que sur les cartes Arc (cœur XMX), sur les autres il bascule sur les instructions DP4a pour exécuter son réseau de neurones. Il est souvent meilleur que le FSR en termes de stabilité, parfois pire. Si un SDK est disponible, il n’expose que des bibliothèques compilées. Le code reste donc fermé.
En parallèle de tout ça, arrive la génération d’image.
Maintenant, en plus d’augmenter la taille d’une « vraie » image générée virtuellement à l’ancienne, on va intercaler 1, 2, voir 3 images interpolées. Générées soit de façon analytique, soit via un réseau de neurones. C’est vendu sous le nom de Frame Generation par nVidia et AMD.
Côté AMD, il faut attendre le FSR 4 pour voir une utilisation d’un réseau de neurones.
Sources : Notebook Check et Digital Foundry
Le FSR fournit alors de bons résultats, et s’il reste légèrement moins qualitatif que le DLSS 4, il représente un saut appréciable par rapport au FSR 3. AMD ferme cette technologie aux cartes RX9000 en RDNA4, évoquant lui aussi l’usage d’instructions dédiées (FP8). Le code source n’est pas officiellement disponible, mais suite à une erreur de publication, le code d’une version du FSR 4 est publié en août 2025.
C’est plutôt ballot et cocasse pour AMD, car en plus de ne pas être voulu, cette version libérée comporte une implémentation fonctionnant sur INT8 du FSR 4. Or, nul besoin de la dernière génération de carte AMD pour les avoir. Ce qui veut dire, et les joueurs vont vite le démontrer en compilant eux-mêmes leur version, qu’il fonctionne en fait sur les cartes d’anciennes générations. Les cartes RDNA2 par exemple, plus vieilles de deux générations que les RX9000 en RDNA4, l’exécutent sans problème. Les cartes RTX 30 de nVidia également. Et si le gain en performance est inférieur aux cartes plus récentes, il reste présent et la qualité — surtout — augmente.
On peut d’ailleurs se demander si cette version du FSR 4 n’est pas la base technique du PSSR de Sony, développé par AMD à destination de la Playstation 5 qui embarque une architecture proche des cartes RDNA2 (elle est hybride). AMD est de son côté resté très silencieux sur le sujet.
On peut imaginer une décision court-termiste pour tenter de gonfler les ventes de la génération 9000, l’avenir dira si c’est un pari payant ou si les joueurs perçoivent cela comme une grossière insulte.
Il en reste la sensation d’un rendez-vous manqué, où le FSR4 aurait pu devenir de fait la méthode de mise à l’échelle universelle, car libre et indépendante de l’architecture. Mais sans qu’on sache exactement pourquoi, elle restera propriétaire et fermée à une gamme de carte.
Bref, à l’heure actuelle, seul les FSR 1, 2 et 3 sont libres et intégrables dans les moteurs de rendu libres comme Godot. Le DLSS et le XeSS restent utilisables pour qui en a la volonté. Le projet J.E.N.O.V.A qui permet notamment de coder en C++ sans passer par les GDExtenssions, utilise le DLSS par-dessus Godot et implémente le raytracing via le kit RTX de nVidia, mais cette portion est propriétaire pour le moment.
Ah ! Et bien entendu, à l’exception des FSR 1, 2 et 3, toutes ces technologies ne gèrent que DirectX. Sous Linux il faut donc passer par Wine / Proton / DXVK pour les exécuter.
DLSS 5
Annoncé en 2026, le DLSS 5 n’est pas une itération du DLSS au sens classique du terme, ce n’est ni de l’upscaling ni de la génération d’image. Le DLSS 5 prend en entrée la couleur et les vecteurs de mouvement d’une image, et utilise un modèle d’IA pour y injecter un éclairage et des matériaux photoréalistes, de façon déterministe et stable temporellement d’après nVidia.
Le système est a l’état de preuve de concept, nécessitant deux RTX 5090 : l’une pour jouer, l’autre exclusivement pour faire tourner le DLSS 5. L’utilisation d’une seule carte reste l’objectif pour la sortie prévue à l’automne 2026. On bascule d’une amélioration de rendu, à une génération de rendu. Ce changement de paradigme est loin de faire l’unanimité. Si l’image que vous voyez est en grande partie inventée par un réseau de neurones, s’agit-il encore du jeu que les artistes ont conçu ?
Dira-t-on bientôt à un assistant dans Unreal : « Voilà mon niveau de test fait de boîtes simples, transforme-le en cathédrale. » ? Cela mènera-t-il à une uniformisation des graphismes ? À une crise pour les artistes 3D ?
Source : nVidia
Tout est possible. Il est également possible que les joueurs ne veuillent pas de cette technologie. Mais si actuellement les rendus peuvent se trouver dans la vallée dérangeante, il y a fort à parier que ça va rapidement devenir indiscernable d’un rendu classique de très haute qualité. Une fois la boîte ouverte, difficile de la refermer.
Reste le problème de confier la direction artistique à une machine, et le fait que cette technologie est encore une fois propriétaire.
Et ça c’est un problème plus important qu’on ne le penserait, car il concerne en fait plus d’utilisateurs que les libristes convaincus. En effet, si nVidia avec son DLSS 5 altère à ce point le rendu des jeux avec un réseau de neurones, il y a fort à parier qu’AMD et Intel vont suivre.
Mais pas avec le même modèle, pas avec la même technique. Et donc produiront un résultat différent. On peut donc craindre que selon la carte de l’utilisateur, le rendu soit variable.
La méthode enjolive l’image à un tel point qu’on peut également imaginer se passer de toute autre technique d’illumination pour revenir à de la pure rastérisation. Le raytracing étant alors relégué aux oubliettes des méthodes de rendu. Beaucoup de questions et peu de réponse, on verra bien.
Après cette première présentation du DLSS 5 qui a laissé les joueurs assez mitigés, nVidia a tenu à montrer d’autres usages du rendu neural, avec une présentation au GDC 2026 faisant la démonstration du NTC (Neural Texture Compression). Un système de compression de texture basé sur un réseau de neurone.
Implémentation par moteurs
L’intégration des technologies d’upscaling et de rendu avancé dans un moteur est une tâche qui peut être complexe.
Sur les moteurs propriétaires, Unreal Engine 5 intègre nativement le raytracing, le DLSS, le FSR et le XeSS. Epic a les moyens pour maintenir ces intégrations à jour et a un soutien de nVidia, AMD et Intel.
Unity les gère également. Ne les utilisant pas je ne saurais en parler avec pertinence, ça a l’air de très bien fonctionner. Il est intéressant de noter qu'Intel ne publie plus son plugin Xess pour Unity, pendant que le DLSS est implémenté au travers du High Definition Render Pipeline
Pour les moteurs libres comme Godot, la situation est différente.
Le raytracing n’était pas forcément une technologie très pertinente ni très facile à implémenter pour des jeux indépendants il y a quelques années. Il n’y a donc pas eu de vrai volonté de l’implémenter, d’autant que d’autres techniques plus classiques existent et fonctionnent sur toutes les cartes, permettant un rendu très qualitatif.
Mais cette situation qui est restée au point mort pendant quelques années a changé assez rapidement, avec une PR pour « mettre en place la plomberie nécessaire au raytracing ». Elle a été intégrée début 2026 dans la version 4.7, et dans la foulée nVidia a publié un fork de Godot supportant le pathtracing et le DLSS. Cette expérimentation ne prend en charge actuellement que les cartes nVidia, mais se base sur la PR mentionnée plus haut, et devrait à terme permettre un pathtracing agnostique de la carte utilisée.
À voir cependant si elle sera intégrable en l’état, ayant été codée avec l’aide de Claude et de Cursor. Elle permet en tout cas de montrer ce qui est actuellement possible en utilisant les briques bas niveaux de Godot, et permet d’espérer voir le tracé de rayon officiellement utilisable avec le moteur dans un avenir proche. Pour rester indépendant d’un vendeur de carte, il faudra aussi intégrer un débruiteur en remplacement de celui utilisé, spécifique à nVidia. Cette vidéo de Leroy Sikkes de chez nVidia au GDC 2026 présente toute la méthodologie du projet.
Le FSR 3 (le dernier à être resté libre et agnostique) est intégrable, mais actuellement seul le FSR2 est disponible sans compiler une PR. Le DLSS et le XeSS le sont aussi techniquement, via des greffons communautaires ou officiels, mais requièrent une acceptation de licences propriétaires. Ils ne seront certainement jamais intégrés directement dans le moteur, pas sans changement de licence. Le FSR 4 tombe dans la même catégorie pour le moment du fait de l’incertitude sur sa licence, même si l’implémentation publiée par erreur par AMD était utilisable, elle concerne DirectX, et non Vulkan, et ne pourrait être exécutable que sous Windows (ou éventuellement via Wine/Proton/DXVK).
Si on regarde du côté de Bevy, des contributeurs ont proposé des implémentations du DLSS, du FSR et même un début d’implémentation du raytracing avec Solari. Les articles rédigés par l’auteur de Solari sont d’ailleurs fabuleux.
Au-delà de tout ça, dans le but de réduire l’impact sur les performances et de produire un meilleur résultat, les technologies de raytracing se voient souvent complétées par des dé-bruiteurs et une pelletée de technologies propriétaires assistées par IA.
Source : Dépôt NRD
L’image brute d’un rendu par lancer de rayon est un champ de points colorés aléatoires. Pour en faire une image propre, il faut la débruiter, et c’est là que l’écosystème de technologies se remet à foisonner.
On peut les classer en deux familles : les débruiteurs analytiques (qui utilisent des algorithmes et du filtrage) et les débruiteurs neuraux (qui utilisent des réseaux de neurones entraînés sur des données de rendu). Les premiers ne nécessitent généralement par une carte particulière alors que les seconds ne sont compatibles qu’avec certaines gammes de cartes.
L’écosystème construit par nVidia est le plus propriétaire de tous, mais c’est de loin le plus complet et le plus documenté. C’est le RTX Kit, il propose le NRD — NVIDIA Real-time Denoiser, un débruiteur analytique qui fonctionne par accumulation temporelle de pixels sur plusieurs frames, et interpolation spatiale entre pixels voisins. Le NRD (une fois n’est pas coutume) est disponible en source ouverte, agnostique de l’API (DX12 et Vulkan), et peut donc être intégré dans n’importe quel moteur.
nVidia fournit également le Ray Reconstruction, un débruiteur neural. Il reconnaît les différents types d’effets raytracing pour prendre de meilleures décisions sur l’utilisation des données temporelles et spatiales, et conserve des informations haute fréquence que les débruiteurs classiques ont tendance à lisser.
Enfin le NRC (Neural Radiance Cache) utilise des réseaux de neurones pour estimer la lumière indirecte avec plus de précision. Extrapolant un éclairage indirect avec moins de lancer de rayons.
AMD a longtemps été en retard sur toute cette gamme de techniques de débruitage et d’amélioration, de même qu’avec l’implémentation et les performances en raytracing. La situation s’améliore avec FSR Redstone, qui veut agréger les technologies dévelopées par AMD dans le but de proposer un équivalent au RTX Kit, mais le retard reste mesurable.
Ainsi l’équivalent AMD du Ray Reconstruction de nVidia est le FSR Ray Regeneration. Un débruiteur basé sur un réseau de neurones qui prédit et restaure les détails raytracing. Il ne nécessite pas d’être lié à un framework de rendu spécifique, ce qui est un avantage pratique. La qualité est apparement en dessous de ce que propose nVidia.
Le FSR Radiance Caching est conceptuellement proche du NRC de nVidia, mais AMD est encore en phase de déploiement — la mise en production était prévue pour 2026.
AMD n’a pas de débruiteur analytique grand public équivalent au NRD, ce qui laisse encore un trou dans sa raquette pour les cartes qui ne peuvent pas utiliser le FSR Redstone.
Intel est le moins avancé des trois sur ce front. Son offre se concentre autour de XeSS 2.
XeSS 2 comprend trois technologies : XeSS Super Resolution (la mise à l’échelle AI), XeSS Frame Generation (interpolation de frames), et Xe Low Latency (XeLL), qui s’intègre au moteur de jeu pour réduire la latence d’entrée.
Intel n’a pas de débruiteur neural dédié au raytracing comparable au Ray Reconstruction ou au FSR Ray Regeneration. Pour le débruitage, les jeux utilisant les cartes Arc sont tributaires des débruiteurs intégrés aux moteurs (NRD si le développeur l’a intégré, débruiteurs propriétaires des moteurs comme Lumen, etc.).
Il faut mentionner que depuis des années, Intel et la communauté open source proposent Open Image Denoise (OIDN), un débruiteur libre basé sur des réseaux de neurones, utilisé notamment dans Blender et d’autres applications de rendu offline.
Également des algorithmes comme ReSTIR visent à réutiliser les tracés d’une image précédente pour réduire le temps de rendu.
Impact sur les performances
Pour se faire une bonne idée de l’impact du raytracing, il peut être intéressant de comparer des titres usant de cette technologie et de la rastérisation plus classique.
Cyberpunk 2077 est par exemple une vitrine du raytracing et du pathtracing.
Cette vidéo donne un bon aperçu technique, pour un rendu en 1440p, avec DirectX12 et en qualité utra. Une RTX 4070 Ti passe ainsi de 100 IPS en rastérisation à 80 en raytracing puis à 51 en pathtracing. La RX 7900 XTX d’AMD elle part de 134 IPS, puis 59 en raytracing et 20 en pathtracing. Et les deux carte utilisent DLSS/FSR pour atteindre ces chiffres.
La perte d’IPS est abyssale chez AMD, la faute à une première implémentation du raytracing alors que nVidia en était déjà à sa troisième itération. La situation s’est un peu améliorée avec les générations suivantes.
Techspot propose un comparatif très complet, avec non seulement l’écart de performance entre rastérisation pure et raytracing mais aussi avec les visuels pour constater (ou non) l’apport du raytracing.
Ce qu’on voit immédiatement c’est que dans beaucoup de jeux, la différence visuelle est minime. Les techniques classiques sont en effet terriblement efficaces pour imiter les effets de lumières, d’occlusion ambiante, d’éclairages indirects, etc. Sur d’autres titres (comme Cyberpunk), l’impact est beaucoup plus visible. Il y a donc une différence liée à l’utilisation du raytracing. La plupart des jeux présentés dans le comparatif utilisent le lancer de rayon dans une approche hybride, en complément de la rastérisation.
L’impact sur les performances est réduit, de même que la différence visuelle. Par ailleurs, la direction artistique change également la donne. Si un niveau ne comporte aucune surface réflective, on aura du mal à constater l’apport du raytracing.
De manière générale, si le lancer de rayon est pleinement utilisé, on table sur environ 30-50% de performances en moins. Et c’est déjà fantastique si on se rappelle d’où on vient.
Dans sa publication THE RENDERING EQUATION, Kajiya présente deux images qui font 256 × 256 pixels, générées sur un IBM-4341. La première ayant pris 401 minutes de temps CPU et la seconde 533 minutes.
On arrive aujourd’hui, 40 ans plus tard, à rendre des images en 4K avec une fluidité suffisante pour le temps réel. En outre, il est probable de voir les performances de rendu augmenter dans les prochaines années.
Impact sur le développement
Le raytracing et le pathtracing, c’est génial, mais pour le développeur qui doit sortir un jeu, ça représente un sacré paquet de nouvelles contraintes.
Déjà, le matériel supporté. Si vous développez un jeu avec le pathtracing comme pilier central, vous excluez de fait une bonne partie de votre audience potentielle. Les cartes avec des unités matérielles dédiées au lancer de rayon restent, en 2026, loin d’être universelles. D’après les enquêtes de Valve, la moitié des cartes les plus utilisées ne le gère pas ou pas très bien.
Les joueurs sur des machines plus modestes, ou sur des cartes trop anciennes, ne pourront pas jouer à votre jeu — ou joueront dans des conditions dégradées. Pour un studio qui vise la plus large audience possible, c’est compliqué.
C’est d’ailleurs pourquoi la plupart des jeux qui utilisent le raytracing le font de manière hybride. On conserve la rastérisation comme base, et assaisonnent avec du lancer de rayon sur certains effets précis : les reflets, les ombres, l’occlusion ambiante. Le raytracing est un bonus visuel pour ceux qui ont le matériel pour en profiter, pas une fondation sur laquelle repose tout le rendu. Mais certains jeux comme Indiana Jones et le Cercle Ancien utilisent explicitement et uniquement le lancer de rayon, rendant leur utilisation impossible sans une carte récente au grand dam des joueurs les moins bien lotis.
Pour le développeur, cela signifie qu’il faut souvent maintenir deux méthodes de rendu en parallèle : la rastérisation (et toutes ces techniques raffinées), et le raytracing. Deux approches très différentes, deux séries de bugs potentiels, deux validations distinctes. Conduisant inévitablement à un surcoût appréciable.
Le raytracing a besoin d’accéder à l’intégralité de la géométrie de la scène pour fonctionner, y compris ce qui n’est pas visible à l’écran. Là où la rastérisation peut se permettre d’ignorer allègrement tout ce qui est hors champ (autant que faire se peut). Le lancer de rayon, lui, doit potentiellement rebondir sur n’importe quelle surface. Cela implique de gérer des structures d’accélération (les BVH, Bounding Volume Hierarchies) qui doivent être mises à jour à chaque image pour les objets en mouvement. Un coût supplémentaire, là encore, même si c’est ce qui permet notamment d’afficher des réflexions complètes.
Du côté des artistes 3D, le passage au raytracing change aussi les habitudes de travail. Une part fascinante de ce métier consiste justement à tricher habilement : placer des sources de lumière pour compenser l’absence d’illumination globale, peindre à la main des cartes de lumière, jouer avec des sondes de réflexion, développer des shaders en araméen à la limite de la prestidigitation et du pacte diabolique. Des techniques qui demandent de l’expérience et un certain sens artistique du bricolage et de l’adaptation.
Avec une propagation de la lumière physiquement réaliste, certaines de ces astuces deviennent complètement inutiles — ce qui peut être un soulagement — mais certaines habitudes et flux de travail doivent être abandonnées ou repensées. Une lumière placée à un endroit étonnant pour une raison purement artistique va se comporter différemment dans un moteur qui simule la physique réelle de la lumière.
D’un autre côté, le fait de pouvoir visualiser le comportement réaliste de la lumière et des réflexions dans une scène permet aussi de s’en approcher plus finement avec les techniques classiques.
Le raytracing peut simplifier certains aspects du travail (plus besoin de calculer à l’avance des lightmaps, les réflexions et les ombres se génèrent automatiquement; tout ceci avec un coût en termes de performance. Un coût d’autant plus pesant que le prix des composants s’est envolé à cause de l’intelligence artificielle.
La question du DLSS 5 et plus généralement du rendu neural mentionnée plus haut ajoute une couche de complexité supplémentaire. Si le rendu peut être altéré (voir complètement généré) par un réseau de neurones, la notion même de direction artistique devient discutable.
Les artistes conçoivent une ambiance, une intention visuelle. Disent des choses au travers les images, la musique. Mais si tout passe ensuite dans une boîte noire qui réinterprète différemment ses entrées selon la carte du joueur, qui est vraiment responsable du résultat final ?
Sera-t-il encore satisfaisant pour les créateurs et les joueurs de concevoir des mondes virtuels dans ces conditions ?
C’est une question que l’industrie commence à peine à se poser sérieusement, et elle se pose pour toutes les œuvres artistiques depuis l’avènement de l’IA.
Enfin, si le développement se fait avec un moteur libre comme Godot ou Bevy, la situation est encore un peu particulière. On l’a vu plus haut, l’écosystème du raytracing et ce qui gravite autour est aujourd’hui dominé par des technologies propriétaires. Et les moteurs libres, par définition, ne peuvent pas les intégrer directement sans franchir des lignes qui iraient à l’encontre de leurs principes — et au moins de leur licence.
Concrètement, ça veut dire que le développeur qui choisit Godot aujourd’hui pour faire un jeu avec du raytracing va défricher un territoire sauvage. Les briques de base existent mais rien n’est prêt à être utilisé sans se retrousser les manches sérieusement.
Pour la mise à l’échelle, le FSR 2 est disponible, le FSR 3 intégrable. Les DLSS ou XeSS peuvent être implémentés, mais avec des licences à accepter, ce qui rend improbable toute intégration officielle dans le moteur. Le développeur qui veut tout ça devra donc assembler lui-même sa chaîne, en acceptant de dépendre de solutions tierces dont la maintenance n’est pas garantie par l’équipe de Godot.
Le plugin Solari de Bevy est pour le moment réservé aux cartes nVidia également, ça changera certainement rapidement.
Si on regarde du côté de Wicked Engine par contre on a bien un moteur supportant le raytracing et fonctionnant sur toutes les cartes. Il est un peu plus niche que Godot ou Bevy mais très impressionnant.
Pour revenir à Godot, ce n’est pas forcément un drame. Il dispose de techniques d’illumination globale très capables comme le SDFGI, le VoxelGI, les sondes de reflexion, etc, qui permettent d’atteindre des rendus très convaincants sans lancer un seul rayon. Et pour beaucoup de styles artistiques (jeux stylisés, pixel art, low poly) la différence entre raytracing et rastérisation ne se justifie pas vraiment.
Il y a eu d’autres approches ces dernières années qui ont eu un impact sur les moteurs, les techniques de géométrie virtuelle par exemple. Nanite, disponible dans l’Unreal Engine en est un bon exemple.
Les maillages sont découpés en hiérarchies de clusters de triangles lors de l’import, puis ces clusters sont échangés à la volée selon la vue caméra, sans couture visible. Remplaçant les techniques plus communes de LOD. En pratique, ça veut dire qu’on peut importer directement des scans photogrammétriques de plusieurs millions de polygones, sans passer par les étapes habituelles de re-topologie et d’optimisation. Permettant de ne plus se soucier du budget de polygones et des LODs.
Du moins dans certaines limites. Si cette approche permet d’avoir des transitions inexistantes entre différents niveaux de détails, il n’en reste pas moins que dans beaucoup de cas, une utilisation des LODs et un bon travail d’optimisations des ressources et du maillage permet d’atteindre de meilleures performances. Importer les yeux fermés des object 3D de plusieurs millions de polygones sans même s’en soucier implique forcément des cas sous optimisés. Mais la technologie est là et mature tranquillement.
Introduction To Modern Rendering présente d’une façon digeste et intéressante les technologies du raytracing et des mesh shader.
Du côté des moteurs libres, c’est en chantier. La proposition pour Godot date de 2021, ouverte peu après l’annonce d’Unreal Engine 5, et est toujours ouverte. Rien de concret n’a atterri dans le moteur à ce jour. Bevy est plus avancé sur le sujet : son contributeur JMS55 (encore lui, c’est la personne derrière Solari) travaille activement sur une implémentation, et son article sur la version 0.16 détaille les avancées récentes — notamment l’amélioration de la qualité du DAG (la hiérarchie de clusters). C’est encore une fois très agréable de lire ces articles riches de détails et accessibles.
Bref, pour qui veut être à la pointe de la technique sans passer par du code propriétaire, la route est encore longue. La bonne nouvelle, c’est qu’elle est libre.
De nouveaux venus (Moore Threads, Lisuan Technology)
Le marché des GPU est depuis très longtemps un duopole de fait entre nVidia et AMD, avec Intel en troisième position encore fragile. Bon, OK, nVidia rafle l’essentiel du marché. Mais AMD tire son épingle du jeu (et sous Linux ils jouissent d’une réputation bien plus reluisante que nVidia).
Mais depuis quelques années, avec le contexte géopolitique tendu, la Chine a accéléré le développement de ses propres fabricants de cartes graphiques. Les restrictions américaines à l’exportation de composants avancés vers la Chine, qui concernent notamment les GPU nVidia les plus puissants, n’y sont pas pour rien.
Deux sociétés font parler d’elles : Moore Threads et Lisuan Technology.
Moore Threads est la plus ancienne des deux, fondée en 2020 par Zhang Jianzhong, ancien vice-président de nVidia Chine. Ses cartes actuelles, les MTT S80 et S90, existent depuis quelques années déjà, mais sont restées assez loin derrière la concurrence. Pour la prochaine génération, basée sur l’architecture Huagang, Moore Threads annonce pour sa puce Lushan des gains de 15x en performance dans les jeux AAA, 50x en raytracing, et 16x en traitement géométrique. Des chiffres spectaculaires, mais sans spécifications ni données de benchmarks à l’appui pour l’instant. Et bien sûr, tout dépend d’où on part.
À prendre avec des pincettes donc, mais l’ambition est là et les moyens aussi. La MTT S90 serait au coude à coude avec la RTX 4060.
Ce qui n’est pas une mince affaire pour un fabricant qui n’existait pas il y a 6 ans.
Lisuan Technology est un peu plus récente encore puisque fondée en 2021. Aucune carte n’est encore sortie (même si les envois auraient commencé).
La carte gaming LX 7G106, fabriquée par TSMC en 6nm, est prévue pour le 18 juin 2026 en Chine. En termes de performances synthétiques, elle se situerait dans les parages d’une RTX 4060.
En revanche, la carte ne supporte pas le raytracing.
Ce qui est notable pour nos sujets, c’est que ces deux acteurs, à des stades différents de maturité, arrivent dans un écosystème où les technologies de rendu avancé sont dominées par des standards propriétaires. Pas de DLSS, pas de FSR 4, pas de Ray Reconstruction. Ils devront soit implémenter leurs propres équivalents, soit s’appuyer sur les technologies agnostiques comme le FSR 2/3 ou le NRD d’nVidia.
Leur impact sur le marché mondial restera sans doute limité à court terme, les joueurs ayant de solides alternatives. Mais pour le marché chinois, qui représente une part considérable des joueurs PC mondiaux, ces alternatives domestiques ont une pertinence réelle, et représente des enjeux en termes d’autonomie. Si l’un d’eux parvient à produire une carte compétitive avec des pilotes stables, ce sera un signal fort que le quasi-monopole de nVidia n’est pas éternel.
Espérons que les pilotes seront libres et les technologies développées aussi, ce serait bien.
Et les performances dans tout ça
On a vu défiler beaucoup de technologies dans cet article. Des acronymes abscons, des architectures, des promesses de gains en tous genres. Mais si on prend un peu de recul : est-ce que tout ça rend les jeux plus agréables à jouer ?
Non. Bien sûr. Évidemment.
Attention, je suis aussi sensible que n’importe qui à de beaux graphismes, mais le nerf de la guerre n’est pas là. Surtout quand on voit que le prix des GPU, du stockage, de la RAM et par effet de bords, de tous les éléments d’un PC, ont flambé ces dernières années. Sous l’effet de la demande apparemment infinie de l’industrie de l’IA. Les cartes qui permettent de profiter correctement du raytracing et des technologies qui l’accompagnent se situent dans des gammes de prix de plus en plus élevées.
Leur consommation ne cesse de grimper (une RTX 5090 est une grosse brique tant son radiateur est gros), de même que leur impact écologique. On parle tout de même de composants PC tellement énergivores qu’ils forcent à changer toute l’alimentation de la machine et amènent avec eux une nouvelle norme de connecteur d’alimentation (qui n’a pas forcement très bonne presse).
Et même à des niveaux plus raisonnables, une carte milieu de gamme récente représente un investissement conséquent pour un résultat qui, on l’a vu, n’est pas toujours spectaculairement supérieur à ce qu’on obtenait avant.
L’augmentation des prix est telle que la demande pour des cartes mère en DDR3 poussent certains fabriquant à renouveler leurs stocks.
Ensuite, le Raytracing, les DLSS, FSR, débruiteurs neuraux, la génération d’images, la géométrie virtuelle. Chacune de ces technologies a été conçue pour résoudre un problème (parfois causé par la technologie qui le précède), et chacune en a introduit de nouveaux. Des artefacts visuels, de la latence, des incompatibilités entre fabricants, des exigences matérielles toujours plus élevées, des licences propriétaires. L’empilement de solutions finit par former une pile fragile, le jeu vidéo est un assemblage hétéroclite de techniques barbares et sauvages depuis ses débuts, mais on commence — avec ces nouvelles technologies biberonnées à l’IA — à s’éloigner de la recherche algorithmique pure, de cet esprit MacGyver qui caractérise si bien le développement de jeux vidéos, pour arriver sur une logique de boîte noire.
Ou bien c’est dans la droite ligne de l’héritage des pionniers du jeu vidéo, et ce sentiment n’est en fait qu’une incompréhension face à une révolution trop rapide pour être assimilée correctement.
Face à ça, aller à contre-courant est non seulement possible, mais peut être couronné de succès. Des jeux comme Celeste, Hollow Knight, Vampire Survivor ou plus récemment Balatro, n’ont aucun raytracing, géométrie virtuelle ou débruiteur neural. Ils tournent sur des machines modestes, parfois vieilles de dix ans ou plus, et se jouent avec un plaisir non moins vif.
À l’autre bout du spectre, des productions AAA ultra-techniques ont déçu leurs joueurs malgré — ou parfois à cause de — leur sophistication technique. Comme Pokémon Legends: Z-A qui (au-delà son contenu vidéoludique) souffre d’un manque flagrant d’optimisation, ce qui est un comble quand on parle de la licence Pokemon. Une licence dont les premiers jeux repoussaient les limites de leur support physique.
La technique se remarque essentiellement quand elle est mauvaise. Une conception ancienne mais bien réalisée sera souvent plus agréable qu’une autre plus récente mais à l’implémentation faillible.
De plus en plus de joueurs en ont marre de devoir investir dans des composants toujours plus puissants et réclament des jeux plus optimisés. Mais les grandes compagnies ont apparemment d'autres préoccupations.
La rastérisation bien maîtrisée, avec les techniques classiques évoquées en début d’article, permet encore en 2026 de produire des rendus magnifiques et des expériences fluides sur le parc matériel le plus large. Des moteurs comme Godot, même sans SDFGI ou sondes de réflexion, permettent d’atteindre des résultats visuellement très convaincants sans toucher les limites du matériel.
Je ne doute pas que le raytracing apporte énormément au jeu vidéo, ses qualités sont indéniables. Seulement dans le contexte actuel, je ne cracherais pas sur plus d’optimisation.
Possédant un Steam Deck de Valve, j’aime le fait de pouvoir baisser la consommation du SOC de la console à 3 ou 5 watts.
Ça rend la machine silencieuse, efficiente, et la batterie tient plus longtemps.
Jouer à Batman: Arkham Knight dans ces conditions permet d’atteindre 60 image par secondes quasiment tout le temps. Ce qui est impressionnant, car en plus le jeu est vraiment très beau.
Il a déjà 11 ans, mais reste magnifique. On pourra se rappeler qu’en 2015 il avait souffert de sa mauvaise optimisation.
La grogne des joueurs poussant Rocksteady Studios à mettre la distribution en pause, le temps de résoudre les problèmes techniques avec l’aide d’AMD et nVidia. Problèmes qui auraient évidemment pu être remontés et corrigés en phase de test.
Aujourd’hui on voit des jeux sortir sans la prise en charge de certaines cartes, comme Crimson Desert (qui recevra finalement plus tard la gestion d’Intel), des performances désastreuses à l’image de Borderlands 4 qui semble avoir réussi à transformer ses joueurs en bêta-testeurs, ou bien découpés à la tronçonneuse pour le vendre petits bouts par petits bouts : (Les Sims 4 on parle de toi).
Alors, quand en plus de ces problèmes que les industriels du jeu vidéo nous ont apportés, on ajoute du raytracing uniquement pour surfer sur la vague, ça ne fait qu’enfoncer le clou dans le cercueil de nos machines.
D’un autre point de vue, et en mettant de côté le raytracing, les technologies comme le DLSS et le FSR permettent de prolonger la durée de vie d’un matériel vieillissant. En tout cas, si ce n’est pas utilisé comme un pansement pour palier des performances passables.
Heureusement, des productions comme Resident Evil 4 ou Red Dead Redemption 2 montrent qu’il est encore possible de faire des jeux visuellement magnifiques (et surtout de bons jeux) qui tournent avec trois fois rien. Split Fiction (qui possède un gameplay en perpétuelle évolution), est visuellement superbe et tourne au poil sur une RX580.
Source : The Gamer
On aura sûrement le meilleur des deux mondes un jour ! Enfin j’espère, sinon on pourra toujours se réfugier dans le jeu de rôle papier.
Connexion
