GDC: Async Compute et AotS : des détails

Tags : DirectX 12; GDC; GDC 2016;
Publié le 21/03/2016 à 14:54 par
Imprimer

Lors d'une session d'AMD dédiée à DirectX 12, Oxide est revenu sur son implémentation du multi engine ("Async Compute") dans Ashes of the Singularity. L'occasion de comprendre comment cette fonctionnalité est exploitée pour booster les performances sur les GPU qui sont capables de prendre en charge plusieurs files de commandes.

Exploiter le multi engine pour booster les performances implique de traiter simultanément différentes tâches. Aucun GPU n'étant actuellement capable de traiter plusieurs files de type graphiques en parallèle (mais cela pourrait changer dans le futur), il y a deux groupes de tâches qui peuvent profiter d'un boost de performances dans DirectX 12 : les copies et les compute shaders. Les premières auront surtout de l'intérêt dans le cadre du multi-GPU et ce sont donc les seconds auxquels les développeurs vont devoir s'intéresser. La première étape est alors de déterminer quels sont ces compute shaders qui peuvent être isolés du reste du rendu et exécutés simultanément via une file dédiée.

Dans le cas du moteur d'Ashes of the Singularity (AotS) il y a 2 larges pans du rendu qui sont traités via des computes shaders : l'éclairage et les ombres d'une part et le post processing d'autre part. Ils représentent à peu près 30% du temps de rendu d'une image typique et semblent donc être de bons candidats. C'est particulièrement le cas pour le post processing qui intervient en fin de rendu et peut sans problème être traité pendant que le travail commence sur une nouvelle image.

Tout du moins c'est la théorie basique. En pratique la prise en compte par le moteur graphique du rendu de plusieurs images en parallèle est un peu plus complexe. Seules les files graphiques peuvent présenter l'image au moteur d'affichage, les files compute en sont incapables. Or il est compliqué, voire impossible suivant le moteur, d'alterner des commandes liées à des images différentes à l'intérieur d'une même file. En d'autres termes, de demander l'affichage de l'image 1 au milieu des commandes de rendu de l'image 2 n'est pas si simple.

La solution est d'exploiter une seconde file graphique qui servira exclusivement à présenter les images en vue de leur affichage. Reste que si les pilotes n'ont aucun problème avec cette possibilité, les GPU actuels ne sont pas capables de gérer deux files graphiques en parallèle. Or si la file secondaire doit attendre que la principale soit traitée avant d'être exécutée, cela entraîne une image de latence supplémentaire.

Oxide a cherché à éviter ce désagrément en faisant en sorte créer un maximum d'opportunités d'alternance entre les deux files graphiques via une décomposition du rendu principal de l'image en suffisamment de groupes de commandes. C'est peut-être légèrement moins efficace sur le plan des performances mais entre l'exécution de ces plus petits groupes de commandes, Windows pourra alterner entre les files graphiques et ainsi insérer la commande de présentation de l'image. Au lieu d'une image de latence supplémentaire, Oxide parvient ainsi à ne l'augmenter que de 1/3 à 1/2 image.

Reste le second point qui peut potentiellement être traité en parallèle via une file compute : l'éclairage et les ombres. Il est plus délicat à aborder et Oxide rentre moins dans les détails. Notre compréhension est que seule une partie passe dans une file compute : le filtrage des ombres qui a un coût élevé. Le problème est que cette phase ne peut pas être traitée en parallèle du reste du rendu qui en a besoin. Pour pouvoir malgré tout la paralléliser, Oxide a recours à une approximation : pour chaque image, les ombres sont issues de l'image précédente. Dans un jeu tel qu'AotS, cela passe presqu'inaperçu, mais cette approche ne pourrait probablement pas être utilisée dans un fps par exemple.

Au final, ce recours au multi engine dans AotS permet de gagner environ 15% de performances (voire un peu plus) au prix d'une demi-image de latence supplémentaire (voire un peu moins), ce qui représente un bon compromis. Tout du moins pour les Radeon qui profitent des avantages, contrairement aux GeForce qui actuellement se contentent des désavantages de cette approche.

Vous pourrez retrouver l'intégralité de la présentation d'Oxide ci-dessous :

 
 

Vos réactions

Top articles