Alternate Frame Rendering (AFR) : rendu alterné multi-GPU, du SLI aux animations Blender

Les options de Blender, citées en anglais, sont vérifiées dans le manuel et le code source de Blender 5.2.

Qu’est-ce que l’alternate frame rendering ?

L’alternate frame rendering, ou rendu alterné des images, répartit une suite d’images entre plusieurs cartes graphiques : chacune calcule une image complète, puis la suivante qui lui revient. Avec deux cartes, la première rend les images 1, 3, 5, la seconde les images 2, 4, 6, et les résultats sont envoyés à l’écran dans l’ordre. En théorie, le débit d’images est multiplié par le nombre de cartes. NVIDIA annonçait dans sa publicité jusqu’à 1,9 fois les performances d’une carte seule avec deux cartes en SLI.

L’AFR a été le mode principal des deux grandes technologies multi-GPU grand public : le SLI de NVIDIA, lancé en 2004, et le CrossFire d’ATI puis AMD, disponible depuis septembre 2005.

AFR et SFR : deux façons de partager le travail

• AFR (alternate frame rendering) : chaque carte a sa propre image. Aucune coordination à l’intérieur d’une image, donc peu de pertes, mais les images doivent se suivre sans dépendre les unes des autres.
• SFR (split frame rendering) : les cartes se partagent la même image, coupée horizontalement. Le pilote déplace la frontière selon la géométrie : si le haut de l’image n’est qu’un ciel vide, la ligne de partage descend pour équilibrer la charge.

Pourquoi l’AFR a disparu des jeux vidéo

• Le micro stuttering. Les images arrivent à intervalles irréguliers. Le compteur affiche plus d’images par seconde, mais la fluidité ressentie peut être pire qu’avec une seule carte.
• Aucun gain de latence. Chaque image prend toujours le même temps à calculer : les images arrivent plus souvent, mais la réaction aux commandes du joueur n’est pas plus rapide.
• Les profils. Le SLI dépendait de profils écrits par NVIDIA jeu par jeu. NVIDIA a cessé d’en ajouter le 1er janvier 2021 pour les RTX 20 et les générations précédentes ; depuis les RTX 20, les cartes se relient par des ponts NVLink, à deux au plus.
• Côté AMD, la marque CrossFire a été retirée en septembre 2017 au profit du mGPU, que les Radeon RX 7000 et suivantes ne prennent plus en charge. DirectX 12 et Vulkan permettent un multi-GPU géré par le jeu lui-même, mais peu de studios l’ont exploité.

Pourquoi l’AFR convient si bien au rendu d’animation

Les défauts de l’AFR tiennent tous au temps réel. En rendu précalculé, ils disparaissent : personne ne regarde les images pendant leur calcul, chacune prend des secondes ou des minutes, et la régularité d’arrivée n’a aucune importance. Une fois les simulations précalculées, les images d’une animation ne dépendent pas les unes des autres : rendre l’image 2 ne demande pas d’avoir fini l’image 1. Avec des cartes identiques et des images de coût voisin, le temps total est presque divisé par le nombre de cartes.

La limite est la mémoire. Le manuel de Blender le rappelle : chaque GPU n’accède en principe qu’à sa propre mémoire, sauf des cartes NVIDIA reliées par NVLink avec l’option Distributed Memory Across Devices. En AFR, chaque carte charge la scène entière, qui doit donc tenir dans la plus petite d’entre elles.

Plusieurs GPU dans Blender : ce que fait Cycles

Dans Preferences > System, les cartes cochées sous Cycles Render Devices forment un seul périphérique de rendu : elles travaillent ensemble sur la même image. C’est utile pour une image fixe, qu’un seul Blender calcule plus vite. La fiche rendu multi-GPU détaille ce réglage. Pour une animation, on peut aussi faire de l’AFR à la main, en lançant un Blender par carte. Le rendu d’une animation depuis l’interface est expliqué dans le guide du rendu Blender.

Méthode 1 : un Blender par carte, une image sur deux

L’option -j (--frame-jump) fixe le pas entre deux images rendues. Sur une machine à deux cartes NVIDIA sous Linux, deux terminaux suffisent :

CUDA_VISIBLE_DEVICES=0 blender -b scene.blend -s 1 -e 240 -j 2 -a -- --cycles-device OPTIX
CUDA_VISIBLE_DEVICES=1 blender -b scene.blend -s 2 -e 240 -j 2 -a -- --cycles-device OPTIX

• CUDA_VISIBLE_DEVICES est une variable de NVIDIA qui limite les cartes visibles par une application CUDA, numérotées à partir de 0 comme dans nvidia-smi. Cycles construit sa liste OptiX à partir des cartes CUDA : chaque Blender ne voit donc que la sienne. Sous Windows, dans l’invite de commandes, on la règle avant la commande avec set CUDA_VISIBLE_DEVICES=0.
• -s et -e fixent la première et la dernière image, -j 2 saute une image sur deux. Le premier Blender rend 1, 3, 5, le second 2, 4, 6.
• L’ordre compte : Blender exécute ses arguments dans l’ordre où ils sont écrits. Les réglages d’images doivent précéder -a, qui lance le rendu.
• --cycles-device, placé après --, choisit le type de périphérique (CPU, CUDA, OPTIX, HIP, ONEAPI ou METAL). Dans le code de Cycles, cette option réunit toutes les cartes visibles de ce type, sans tenir compte des cases cochées dans les préférences. Le choix entre CUDA et OptiX est expliqué dans le guide OptiX dans Blender.

Méthode 2 : les fichiers réservés, pour équilibrer la charge

Le manuel de Blender décrit une « ferme de rendu primitive » qui marche aussi entre les cartes d’une même machine. Dans Output Properties > Output, décochez Overwrite et cochez Placeholders, puis lancez autant de Blender que de cartes, tous sur la même plage d’images et vers le même dossier. Chaque instance crée un fichier vide pour l’image qu’elle commence, et les autres passent à la suivante. Une carte plus rapide prend simplement plus d’images : c’est la bonne méthode quand les cartes sont différentes ou que le coût varie beaucoup d’une image à l’autre. Entre plusieurs ordinateurs, il suffit d’un dossier partagé sur le réseau.

Les erreurs fréquentes

• Additionner la mémoire des cartes. Deux cartes de 16 Go n’offrent pas 32 Go à la scène : chacune doit la contenir entière.
• Placer -a avant -s, -e ou -j. Le rendu part avec les réglages du fichier, et les deux Blender calculent les mêmes images.
• Laisser Overwrite coché avec les Placeholders. Les instances réécrivent alors les images déjà faites au lieu de passer à la suivante.
• Oublier de précalculer les simulations. Fluides, tissus et particules doivent être calculés (bake) avant le rendu, pour que chaque instance lise le même cache.
• Utiliser -j avec des cartes différentes. La plus lente reçoit autant d’images que la plus rapide et termine bien après elle ; préférez les Placeholders.
• Attendre un gain sur une image fixe. L’AFR ne sert qu’aux séquences ; pour une image seule, cochez toutes les cartes dans les préférences.

Ce que l’AFR change au temps de rendu

Prenez une animation de 240 images à 2 minutes l’image sur une carte : 8 heures de calcul. Sur quatre cartes identiques en AFR, le rendu tombe à environ 2 heures, plus le temps de chargement de la scène par chaque instance. Le gain est presque linéaire tant que les images ont un coût voisin et que la scène tient dans la mémoire de chaque carte.

Une ferme de rendu applique ce principe à grande échelle, avec des machines entières plutôt que des cartes d’un même ordinateur. Le choix d’une machine personnelle est traité dans le guide du PC pour le rendu 3D, et la répartition d’une animation Blender sur plusieurs GPU, sur la page ferme de rendu 3D. Pour chiffrer la durée de votre propre animation, utilisez le calculateur de temps de rendu.