La règle des 16 Millisecondes (Beyond Pixels, Episode 2)

Beyond Pixels : la révolution du Virtualized Rendering (rendu virtualisé), épisode 2

Du traitement des données au rendu de chaque pixel, le pipeline graphique est un mécanisme de précision qui donne vie à des mondes interactifs, que ce soit pour le jeu vidéo, le cinéma, la simulation ou les jumeaux numériques.
Comme quand on danse, c’est le rythme qui fait toute la différence et créé la magie.

Que se passe-t-il lorsque votre expérience virtuelle saccade (lag) ?
Bien souvent, c’est parce qu’une règle n’a pas été respecté : la règle des 16ms.
C’est une règle simple : tout ce qui est visible dans votre scène (logique, simulation, éclairage, rendu, post-traitement) doit être calculé en 16 millisecondes maximum.
Pourquoi ? Parce que c’est le temps maximum alloué à chaque image pour en afficher 60 par seconde (60FPS).
1 seconde ÷ 60 images = 16,66 ms par image.

Chez SKYREAL, certains développeurs sont « obsédés » par ces 16 ms. Certains vont même jusqu’à dire que ce n’est pas qu’un simple objectif de performance mais le véritable « battement de cœur du temps réel ».
Dans cet article nous observerons comment cela se passe et comment les choses sont en train de changer en profondeur depuis Unreal Engine 5.

Une course contre la montre

On peut voir un moteur 3D comme un facteur marseillais sous caféine : le CPU rédige des cartes postales qui décrivent le monde, le GPU les convertit en images, et le tout doit être réalisé en 16 ms ou moins.

Malek Fardeau, développeur Unreal Engine, originaire de la cité phocéenne.

 

Origine technique de cette règle

Un écran 60 Hz actualise son image 60 fois par seconde.
Cela laisse un temps de 16,66 ms pour réaliser toutes les opérations de rendu (CPU + GPU).
Si une image prend plus de temps à être calculée, cela provoque  une baisse perceptible du nombre d’images par seconde : ça lag.

(nb: les écrans 60 Hz sont devenus la norme dans les années 1990 et se sont largement imposés au début des années 2000.)

Pourquoi la règle des 16 ms est importante bien au-delà du jeu vidéo

Aujourd’hui, les ingénieurs, les designers, les architectes, etc, utilisent les moteurs de jeu temps réel non seulement pour produire des visuels, mais aussi pour prendre des décisions. En effet, le temps réel leur permet d’avoir un retour immédiat lors des phases de conception et des design reviews ainsi qu’une grande interactivité  dans les phases de collaboration immersives qui aide à mieux appréhender des systèmes complexes.

La base de l’optimisation : le Culling, l’art de dire « non » aux draw calls

Un GPU qui shade ce que le joueur ne voit pas gaspille de l’énergie et du temps. Les moteurs appliquent donc un culling strict :

  • Frustum Culling: suppression des objets hors du cône de vision de la caméra.
  • Occlusion Culling: avec les hierarchical Z-buffers (HZB) ou des tests logiciels, on vérifie si un objet est caché derrière une autre géométrie.
  • Backface Culling: on ignore les triangles dont la face est tournée à l’opposé de la caméra, inutile de les shader.

Les objets restants sont regroupés par matériau pour optimiser les calculs. Sous DirectX 12 et Vulkan, cela réduit le nombre de commandes envoyées au GPU.

 

Pipeline graphique monothread et multithread : tenir les 16 ms

Jusqu’à 2010 (environ), le pipeline graphique monothread traditionnel exigeait que chaque tâche soit réalisée séquentiellement dans le laps de temps de 16 ms.
Et pour respecter cela, chaque sous-système devait accomplir sa part rapidement et efficacement :

Stage Budget (60 FPS)
CPU + Culling ≤ 4 ms
Geometry + Raster ≤ 3 ms
Pixel Shading ≤ 4 ms
Post-Processing + UI ≤ 3 ms
Frame Total ≤ 16 ms

 

Depuis 2010, l’adoption généralisée du multithreading a permis aux moteurs modernes de répartir les charges de travail sur plusieurs cœurs CPU. Ce parallélisme permet d’exécuter les tâches simultanément, réduisant considérablement le temps nécessaire pour chaque image. En conséquence, des scènes plus complexes et des effets avancés peuvent être traités efficacement, souvent avec des temps d’image inférieurs à 16 ms.

Réduire le temps par image en dessous de 16 ms permet donc de supporter des fréquences d’images plus élevées (comme la nouvelle norme de 90 FPS dans les jeux vidéo) et d’intégrer des effets visuels potentiellement couteux tels que le ray tracing sans compromettre l’expérience.

Mini étude de cas : ouvrir une porte

Prenons une action très simple comme ouvrir une porte dans une scène 3D. Voici une version simplifiée de ce qui se passe dans une fenêtre de 16 ms :

  1. Le CPU calcule l’animation de la porte the door animation.
  2. Le Culling détermine ce que vous verrez depuis votre point de vue.
  3. Les Shaders calculent les couleurs, textures, éclairages et ombres (geometry shader, pixel shader, vertex shader…).
  4. Le Post-processing ajoute le flou de mouvement, l’anticrénelage, le tone mapping, etc.
  5. Le GPU affiche l’image calculée à l’écran.

Ce sont des millions d’opérations dissimulées derrière un seul mouvement de porte fluide qui semble anodin.

16 ms : une contrainte et une philosophie de conception

Les moteurs modernes comme Unreal Engine 5 bouleversent l’ancien pipeline graphique. A la place d’étapes prédéfinies couteuses en ressources, on dispose désormais de systèmes virtualisés et dynamiques qui n’utilisent des ressources que pour ce que l’utilisateur voit réellement.
Ce changement est rendu possible par les innovations de UE5 :

  • Nanite : supprime des draw calls en streamant la géométrie par cluster.

  • Lumen : permet une globale illumination grâce à une approche hybride intelligente mêlant screen-space et ray tracing.

  • Bindless rendering : supprime les limites de textures et de matériaux, offrant aux artistes plus de liberté sans pénaliser la performance.

Le moteur ne fait plus que traiter des tâches : il hiérarchise, compresse et s’adapte, le tout en temps réel.

En résumé

Il est nécessaire d’avoir une importante puissance de calcul pour tenir la contraintes des 16ms par image et offrir une expérience fluide. Mais depuis Unreal Engine 5 le fonctionnement du pipeline graphique est abordé différemment et permet d’obtenir des performances à couper le souffle ; cela ouvre des perspectives d’expériences immersives formidables pour les industriels qui disposent de données très importantes en volume.

En d’autres termes et comme le dit Malek :

« Avec un moteur qui envoie du bois on fait des exploits, avec un moteur ancien, dégun »

Chez SKYREAL, nous ne faisons pas qu’optimiser des calculs. Nous donnons vie à des expériences temps réel où chaque milliseconde devient une opportunité de créer et d’innover.