En cabine • Minecraft version RTX

• Path Tracing

Comme nous l'évoquions en débutant ce dossier, Minecraft se met à la mode du lancer de rayons, version Path Tracing plus précisément. Avant de préciser ce qu'il en est de ce dernier, un petit rappel concernant le Ray Tracing (davantage usité que la dénomination française). Son fonctionnement est quelque peu inversé (schéma de droite ci-dessous) par rapport à la traditionnelle rastérisation qui convertit une image vectorielle en matricielle (à gauche).

Le lancer de rayons reconstitue lui, une image virtuelle en suivant depuis la vue utilisateur/caméra, le cheminement des rayons qui traversent le plan 2D de l'image jusqu'aux sources lumineuses, en prenant en compte les principes optiques de réflexions, réfractions ou blocage (conduisant aux ombres) de la lumière. L'avantage est d'obtenir un résultat pouvant être photo-réaliste, expliquant son adoption massive dans le cinéma. La contrepartie est une somme de calculs colossale, ce qui n'est pas forcément handicapant pour un rendu destiné à être inclus dans un film en post-production (précalculé), mais prohibitif pour une exécution en temps réel dans un jeu vidéo...

La réponse apportée par NVIDIA à ce dilemme est pour le moins originale, mais pragmatique : un rendu hybride, conservant une base rastérisation là où cette dernière reste pertinente (Z-buffer, etc.), mais utilisant le Ray Tracing pour les tâches qui donneront de meilleurs résultats avec cette technique (éclairage, etc.). Bien sûr, rien n'empêche de réaliser l'intégralité de la scène avec l'une ou l'autre technique, mais avec la plupart des compromis usuels de ces dernières (qualité ou performance).

Les pipelines de rendu dédiés aux 2 méthodes peuvent travailler de concert, ce qui est à la base du rendu hybride. La somme des calculs à réaliser en Ray Tracing est étroitement liée à la complexité de la scène (définition, nombre d'objets, etc.), mais aussi à la qualité de rendu souhaité. Cette dernière dépend en grande partie du nombre de rayons diffusés par pixel. NVIDIA s'est donc attelé à en limiter le nombre tout en préservant la qualité visuelle. Il use pour cela de nombreux filtres de "débruitage" (denoising), permettant d'améliorer significativement une image, tout en conservant un nombre de rayons compatibles avec l'exécution en temps réel.

Un autre axe de réduction du nombre de calculs, est l'utilisation de la technique Bounding Volume Hierarchy ou BVH. Kesako ? En fait, une part importante de ces derniers est dédiée à "déterminer" le triangle (des objets 3D) frappé par un rayon, afin de déterminer la trajectoire de ce dernier. C'est là qu'intervient ce fameux BVH. En pratique, cet algorithme teste si le rayon touche une "grande" boite de forme géométrique simple (les tests d'intersections sont ainsi "aisés" à réaliser) qui englobe l'objet ou une partie de ce dernier. Si ce n'est pas le cas, il passe à une autre grande boite, si par contre le rayon touche la boite, il effectue une recherche plus fine à l'intérieur de cette dernière via des boites plus petites et ainsi de suite jusqu'à isoler le triangle d'intersection.

Les RT Core entrent alors en scène : leur objectif est de fournir une accélération matérielle au BVH. NVIDIA indique que sur une architecture ne disposant pas de circuit spécialisé, ces opérations coûteraient des milliers de cycles d'instructions supplémentaires par rayon.

Voilà rapidement résumé le Ray Tracing tel qu'implémenté au sein de l'architecture Turing du caméléon, qui rend possible sa mise en œuvre pour les jeux, au sein des derniers GPU des verts. Nous verrons ce qu'il en sera de l'approche d'AMD à ce sujet, mais un brevet déposé par ce dernier semble étayer l'hypothèse que les rouges ont opté eux-aussi pour l'accélération matérielle du BVH. Précisons également que cette tambouille interne des constructeurs sera transparente pour les développeurs qui utiliserons l'API DX12 Ultimate commune aux PC et Xbox série X, ou Vulkan RT.

Et le Path Tracing alors ? Eh bien c'est toujours du Ray Tracing, toutefois vous l'aurez compris en lisant les lignes précédentes, ce dernier du fait de sa gourmandise, impose d'en faire un usage parcimonieux pour conserver un débit d'images par seconde suffisant. Lors des premières implémentations du RT au sein de jeux, les développeurs ont la plupart du temps limité son utilisation à un certain nombre d'effets (calcul des ombres pour certains, réflexions pour d'autres, etc.), ce qui est possible du fait de l'approche flexible/hybride de Turing.

Le Path Tracing de son côté regroupe tous ces différents aspects permettant la gestion de l'illumination globale d'une scène via un rendu RT et pas juste certains effets. Pour ce faire, des rayons sont lancés de manière aléatoire depuis la caméra jusqu'à constitution complète de la scène. Du fait de son échantillonnage aléatoire, le Path Tracing génère un bruit (grain) altérant la qualité du rendu. Pour contrebalancer cet effet indésirable, une solution consiste à recombiner plusieurs images successives (à l'image de ce qui est fait pour un filtre antialiasing temporel par exemple) afin d'éliminer ce grain, comme illustré ci-dessous. 

La charge de calcul induite par le Path Tracing est, vous l'aurez compris, bien plus lourde qu'un simple ajout de réflexions, ce qui explique que seuls des jeux avec un moteur 3D "léger" pour le hardware actuel, soient en capacité d'accepter une telle sollicitation avec des performances honorables en haute définition. A ce jour, Quake II RTX en était un représentant, Minecraft le rejoint avec cette beta.

Les moteurs 3D les plus performants ne permettent pas encore d'accepter une telle gestion de l'éclairage, mais le mouvement est en marche pour un pas supplémentaire au niveau du réalisme des scènes 3D. Le caméléon a de plus sorti un atout supplémentaire de sa manche, afin d'augmenter siginificativement les performances, au prix de concessions visuelles tout à fait acceptables, comme nous allons le voir à présent.   

• Deep Learning Super-Sampling 2.0

Là-aussi, commençons par un petit rappel du mode de fonctionnement de cette technologie NVIDIA, permettant selon son créateur d'offrir des performances en nette hausse, pour une qualité visuelle équivalente à celle atteinte avec un TAA classique. Pour ce faire, le caméléon utilise une build d'un jeu fourni par les développeurs et procède au rendu de dizaines de milliers d'images avec une qualité visuelle parfaite ou presque (64 échantillons par pixel), collectant ainsi le résultat de sortie et les données d'entrée brutes (images en basse résolution et aliasées) qui vont pouvoir être utilisés lors de l'opération d'apprentissage profond (Deep Learning) à venir.

Un réseau de neurones artificiels (de type auto-encodeur convolutif) est ensuite entraîné à obtenir cette qualité de sortie avec ces données d'entrée, au moyen de méthodes fortement matheuses (back propagation), ce qui lui permet "d'apprendre" les spécificités propres à ces images. Il résulte de cet apprentissage un DNN model (Deep Neural Network signifie "réseau de neurones profond") capable d'imiter le comportement observé sur l'échantillon utilisé lors de l'apprentissage, et ce pour un coût bien moindre que la technique originelle. Comment ? Par le biais des Tensor Cores, qui utilisent alors le DNN model sur l'image brute aliasée de définition plus faible, pour infèrer en temps réel le rendu anti-aliasé à la définition d'affichage requise. L'inférence est friande des calculs en faible précision où les Tensors Cores excellent.

Voilà pour la théorie, mais à l'exception notable du tout premier jeu proposant cette fonctionnalité (FFXV), la plupart des réalisations suivantes ont été décevantes avec un rendu souvent flou, comme nous l'indiquions ici ou là par exemple, Battlefield V détenant le pompon à ce niveau. Toutefois, les verts n'ont pas chômé depuis ces premiers essais largement perfectibles, et après une étape intermédiaire encourageante,  la version 2.0 a revu en profondeur l'auto-encodeur convolutif, mais ce n'est pas tout.

Ainsi, la notion de Temporal Feedback a également été ajoutée, comme illustré ci-dessous. Derrière cette dénomination, se cache l'intégration des vecteurs de mouvement, aux données d'entrée collectées en basse résolution. Ceux-ci sont ensuite appliqués à la précédente image de sortie (haute qualité), afin d'estimer plus précisément quelle sera l'apparence de la prochaine. Cela permet de rendre des images plus nettes (au-revoir le flou) tout en améliorant la stabilité d'une image à la suivante.

Un mot supplémentaire concernant l'auto-encodeur : ce dernier est à présent commun à tous les jeux (facilitant et accélérant ainsi son intégration au processus de création). Toutefois, il est toujours nécessaire de générer (via apprentissage profond ou Deep Learning dans la langue de Shakespeare) un DNN Model spécifique à chaque jeu par le biais de ce réseau de neurones.

A noter également que cette seconde itération de DLSS, permet de choisir 3 niveaux de qualité afin de laisser le choix à l'utilisateur : Performance, Équilibré ou Qualité. En pratique, il s'agit de faire varier la définition de rendu avant d'inférer les images qui seront affichées. Control dans sa dernière version propose par exemple pour un affichage en UHD, les valeurs ci-dessous :

On comprend facilement l'intérêt de la technologie, mariant les gains de performance liés à l'upscaling, tout en supprimant la plupart des artefacts visuels qui en découlent par le biais de l'IA. Minecraft intègre bien entendu cette version 2.0 du DLSS, mais du fait de son statut Beta, certaines options ne sont pas encore accessibles. C'est le cas de la qualité qui est fixée pour l'heure au niveau maximal en 1080P, équilibré en 1440P et performance en 2160P.