1, 2 ou 3 cartes graphiques ?

Après avoir réintroduit la possibilité d'exploiter 2 cartes graphiques en parallèle pour augmenter les performances avec le SLI, et s'être planté en beauté avec le Quad SLI qui tentait d'exploiter 2 doubles cartes graphiques, Nvidia a décidé fin 2007 de renforcer son offre multi-GPU avec le 3-way SLI ou triple SLI. L'occasion pour nous de faire le point sur les performances des systèmes SLI et CrossFire.

Le multi-GPU

Le rendu 3D est de par sa nature très largement parallélisable, c'est-à-dire qu'une même opération est exécutée sur un nombre important d'éléments distincts, et ce à plusieurs niveaux. Le traitement de la géométrie, de ses nombreux vertices / triangles peut se faire en parallèle, le calcul des pixels également, et enfin bien entendu le calcul des images.

Il est donc évident qu'il y a là l'opportunité de diviser le travail nécessaire au rendu 3D de manière à exploiter plusieurs processeurs graphiques. Encore faut-il parmi toutes ces possibilités en dégager la plus efficace et arriver à l'implémenter d'une manière performante et robuste dans les pilotes.

Répartir le travail sur la géométrie, à l'intérieur d'une même image, entre 2 processeurs graphiques est faisable, mais plutôt complexe à mettre en place et avec des gains qui ne seraient pas intéressants d'autant plus que le traitement de la géométrie représente une tâche très simple dans de nombreux jeux.

Séparer le traitement de la géométrie du calcul des pixels, avec un processeur graphique dédié exclusivement à l'une de ces tâches et un second à l'autre. Les architectures unifiées permettent en effet aux GPUs d'attribuer toutes leurs capacités de calcul à une tâche bien spécifique. Reste que cela irait à l'encontre du principe même de ces architectures unifiées qui est de répartir suivant la demande les capacités de traitement dont elles disposent.

Répartir le calcul des pixels entre plusieurs GPUs est une solution plus adaptée, tout du moins avec les GPUs classiques qui disposent d'unités de traitement dédiées au calcul des vertices et des pixels. Dans ce cas, chaque GPU va traiter complètement toutes les vertices (gaspillage de ressources dans un sens, mais de toute manière ils ont des unités dédiées qui se tourneraient les pouces ci ce n'était pas le cas), mais seulement une partie des pixels, par exemple, les pixels d'une moitié de l'écran, d'une ligne sur 2, ou de différentes petites zones de l'écran. On parle alors de rendu SFR (split frame rendering).

Cette répartition du travail sur les pixels peut être statique (fixée une fois pour toutes) ou dynamique (qui varie en fonction de la complexité de calcul de chaque zone de l'écran et de la puissance de chaque GPU). Cette solution a l'avantage de pouvoir répartir le travail efficacement entre 2 GPUs de puissance différente si la répartition est dynamique, mais rend difficile des gains de performances importants dans certaines situations. Si son exploitation basique est "aisée", elle peut devenir extrêmement complexe avec des moteurs de jeu plus avancés.

Répartir les images à calculer entre les GPUs est la solution la plus efficace à l'heure actuelle. Avec l'AFR (alternate frame rendering), chaque GPU se charge alors du rendu complet d'une image et n'a pas à se soucier des autres GPUs. Le seul défi à surmonter consiste à s'assurer qu'il n'y ait pas de dépendance entre images. S'il est assez simple d'éviter cela, dans de nombreux cas il revient au développeur du jeu de le faire et non au fabricant du GPU qui est plus ou moins impuissant à ce niveau. C'est la raison pour laquelle la méthode précédente a été au départ privilégiée avant d'être remplacée progressivement dans la plupart des cas par l'AFR qui est plus performant.

Répartir dynamiquement des threads, soit des opérations diverses à exécuter sur des éléments divers aux aussi, est la prochaine étape. Il s'agira avec un peu d'abstraction de répartir la masse de calcul à exécuter entre différentes puces, d'une manière similaire à ce qui se passe entre les différentes unités d'une même puce. Il y a encore de nombreux défis à relever pour y parvenir, notamment au niveau de la communication entre les GPUs et leur mémoire, mais il semble évident que ce soit la voie à suivre pour le futur.