Aller au contenu

1 · Graphique temps réel

Le domaine d'origine. Comprendre le pipeline graphique éclaire des décisions d'architecture qu'on retrouve partout ailleurs — et le domaine est en train de converger vers le calcul général.

1.1 Le pipeline de rasterisation

L'algorithme qui domine le rendu temps réel depuis trente ans.

Sommets (vertices)
    │
    ├─ Vertex Shader        : transforme chaque sommet (programmable)
    ├─ Tessellation         : subdivise (optionnel, programmable)
    ├─ Geometry Shader      : crée/détruit de la géométrie (optionnel)
    ├─ Assemblage           : regroupe les sommets en triangles
    ├─ Clipping, culling    : élimine ce qui sort de l'écran (fixe)
    ├─ RASTERISATION        : triangle → pixels couverts (matériel fixe)
    ├─ Fragment Shader      : calcule la couleur de chaque pixel (programmable)
    ├─ Tests (profondeur,   : élimine les pixels cachés (fixe)
    │  stencil, alpha)
    └─ Blending → framebuffer

L'idée de la rasterisation : pour chaque triangle, trouver les pixels qu'il couvre. C'est un problème massivement parallèle et régulier, et il a littéralement dessiné l'architecture des GPU.

Ce que le pipeline explique

Plusieurs traits du GPU deviennent évidents à sa lumière :

  • le warp de 32 correspond à un carré de 8×4 ou 4×8 pixels — un quad de fragments ;
  • les unités de texture existent parce que l'échantillonnage de texture avec filtrage bilinéaire et mipmapping est trop coûteux en logiciel ;
  • le cache de texture est optimisé pour la localité 2D, pas 1D ;
  • la faible précision (FP16, formats compressés) est acceptable parce qu'une couleur n'a que 8 bits par canal à l'arrivée.

Chiffres actuels : la rasterisation atteint 60 à 240 images/s sur un GPU moderne, et consomme 40 à 60 % de moins d'énergie que le ray tracing pour un résultat comparable en éclairage direct.

1.2 Le ray tracing et les RT cores

La rasterisation est rapide et fausse. Elle ne sait pas naturellement gérer les réflexions, les réfractions, les ombres douces ni l'éclairage indirect — tout cela est approximé par des astuces (cartes d'ombre, sondes de lumière, réflexions en espace écran).

Le lancer de rayons inverse le problème : pour chaque pixel, on lance un rayon et on cherche ce qu'il touche.

pour chaque pixel :
    rayon ← caméra → pixel
    intersection ← trouver l'objet le plus proche touché par le rayon
    couleur ← évaluer l'éclairage à ce point
              + rayons secondaires (réflexion, réfraction, ombre)

Le coût est dans la recherche d'intersection. Avec des millions de triangles, on utilise une structure d'accélération — typiquement une BVH (Bounding Volume Hierarchy), un arbre de boîtes englobantes.

Le parcours de BVH est :

  • irrégulier (chaque rayon prend un chemin différent dans l'arbre) ;
  • divergent (les rayons d'un warp divergent immédiatement) ;
  • dominé par des accès mémoire dispersés.

C'est le profil exactement contraire à ce qu'aime un GPU.

D'où les RT cores : des unités à fonction fixe qui accélèrent en matériel le parcours de BVH et les tests d'intersection rayon-triangle. Les shaders programmables ne s'occupent plus que de l'ombrage.

Le rendu hybride est le régime actuel : rasterisation sur les cœurs shaders pour la géométrie primaire, ray tracing sur les RT cores pour les rayons secondaires (réflexions, ombres, occlusion ambiante).

La leçon transférable

Quand un problème est structurellement hostile au GPU (irrégulier, divergent), une réponse possible est de le câbler dans du silicium dédié plutôt que de l'exprimer en shaders.

C'est exactement le même raisonnement que celui des tensor cores pour les produits matriciels, et de TMA pour le mouvement de données.

1.3 Les compute shaders

Depuis DirectX 11 et OpenGL 4.3, on peut exécuter du calcul général dans le pipeline graphique, sans passer par CUDA.

#version 450
layout(local_size_x = 8, local_size_y = 8) in;
layout(rgba32f, binding = 0) uniform image2D image;

shared float tuile[10][10];    // mémoire partagée

void main() {
    ivec2 coord = ivec2(gl_GlobalInvocationID.xy);
    // ... traitement ...
    imageStore(image, coord, vec4(couleur, 1.0));
}

local_size est la taille de bloc, gl_GlobalInvocationID l'indice global, shared la mémoire partagée, barrier() le __syncthreads(). C'est le même modèle, avec un autre vocabulaire.

Usages typiques en rendu moderne :

Usage Description
Post-traitement flou, bloom, correction colorimétrique, anti-aliasing temporel
Simulation particules, tissu, fluides, chevelure
Culling élimination d'objets et de triangles avant rasterisation
Génération de terrain bruit procédural, érosion
Éclairage différé tiled et clustered shading
Débruitage pour le ray tracing, souvent par réseau de neurones

La tendance de fond : de plus en plus d'étapes du rendu quittent le pipeline fixe pour des compute shaders. Le pipeline « mesh shader » de Turing/Ampere en est l'aboutissement : il remplace les étages vertex/tessellation/geometry par un modèle proche du compute.

1.4 Le Gaussian splatting

L'exemple le plus intéressant de convergence graphique/calcul depuis 2023.

L'idée : représenter une scène 3D non pas par des triangles, mais par des millions de gaussiennes 3D — des taches floues avec position, covariance, couleur et opacité. Le rendu consiste à projeter ces gaussiennes sur l'écran et à les composer par ordre de profondeur.

Nuage de gaussiennes 3D
    │
    ├─ Projection 3D → 2D (compute)
    ├─ Tri par profondeur (compute — un tri par tuile d'écran)
    ├─ Rasterisation des ellipses (compute)
    └─ Composition alpha

Ce qui le rend remarquable :

  • il atteint 60 à 200 images/s pour de la synthèse de nouvelles vues photoréaliste ;
  • il est entraîné par descente de gradient, comme un réseau de neurones — les paramètres des gaussiennes sont optimisés à partir de photographies ;
  • son rendu utilise une rasterisation hiérarchique écrite en CUDA, pas le pipeline graphique fixe.

C'est donc un objet hybride : un algorithme graphique, entraîné comme un modèle d'IA, exécuté par des noyaux de calcul général.

Les développements de 2026 vont vers des pipelines hybrides splatting/maillage et vers le lancer de rayons sur gaussiennes, ce qui recrée la même tension rasterisation/ray tracing dans ce nouveau cadre.

1.5 Ce que le graphique apporte au calcul

Trois techniques nées du rendu et utilisées partout :

1. Le pavage en tuiles. Le tiled rendering découpe l'écran en tuiles traitées indépendamment, pour la localité de cache. C'est exactement le pavage des GEMM.

2. Les niveaux de détail. Choisir la résolution selon l'importance. On retrouve l'idée dans l'attention creuse, la quantification par couche, et les méthodes multi-grilles.

3. Le rendu différé. Séparer « calculer les propriétés géométriques » de « calculer l'éclairage » pour ne pas payer l'éclairage sur des pixels cachés. C'est un principe de fusion et d'élimination de travail inutile.

Résumé du chapitre

À retenir

  • Le pipeline de rasterisation explique l'architecture du GPU : warps, unités de texture, caches 2D, faible précision.
  • Le ray tracing est structurellement hostile au GPU (irrégulier, divergent) ; la réponse a été de le câbler dans des RT cores.
  • Les compute shaders exposent le même modèle que CUDA sous un autre vocabulaire, et absorbent progressivement les étapes du rendu.
  • Le Gaussian splatting est un hybride : algorithme graphique, entraîné par gradient, rendu par des noyaux CUDA.
  • Trois techniques du rendu se transfèrent partout : le pavage en tuiles, les niveaux de détail, la séparation en passes.

Vérifiez que vous avez compris

Pourquoi la divergence est-elle un problème encore plus grave en ray tracing qu'en calcul général ?

Parce qu'elle est immédiate et permanente. Dès le premier rebond, les 32 rayons d'un warp touchent des objets différents, descendent dans des branches différentes de la BVH, et invoquent des shaders de matériau différents.

Il n'y a pas de restructuration simple : le chemin d'un rayon dépend de la géométrie, qui est arbitraire.

Les réponses partielles : le tri des rayons par direction ou par matériau avant l'ombrage (ray sorting), et surtout le câblage matériel du parcours de BVH, qui déplace le problème hors des unités SIMT.

Un compute shader Vulkan et un noyau CUDA sont-ils équivalents en performance ?

Sur les opérations de base, oui, à quelques pourcents près : ils compilent vers les mêmes instructions matérielles.

Les écarts apparaissent sur :

  • l'accès aux tensor cores — CUDA les expose complètement, Vulkan par l'extension VK_KHR_cooperative_matrix, plus limitée ;
  • les mécanismes asynchrones — TMA, wgmma, clusters n'ont pas d'équivalent Vulkan ;
  • les bibliothèques — cuBLAS, cuDNN, CUB n'ont pas d'équivalent portable.

Pour du calcul générique, l'écart est faible. Pour du calcul matriciel de pointe, il est considérable.

Le Gaussian splatting fait 60-200 images/s alors qu'il manipule des millions de primitives triées par profondeur. Comment le tri ne le tue-t-il pas ?

Parce que le tri est local et approximatif, pas global et exact.

L'écran est découpé en tuiles (typiquement 16×16 pixels). Pour chaque tuile, on ne trie que les gaussiennes qui l'intersectent — quelques centaines au lieu de millions. Le tri se fait par clé combinant identifiant de tuile et profondeur, avec un cub::DeviceRadixSort, qui trie à la bande passante mémoire.

C'est une application directe des trois techniques du §1.5 : pavage en tuiles pour la localité, réduction du travail par élimination, et usage d'une primitive parallèle optimale plutôt que d'un algorithme maison.

Chapitre suivant : 2 · Calcul scientifique

Sources de ce chapitre