Les derniers contenus liés aux tags DirectX 12 et GDC 2016

GDC: D3D12, multi-GPU et frame pipelining

Publié le 25/03/2016 à 04:57 par Damien Triolet

Lors de la journée de la GDC consacrée aux tutoriaux liés à DirectX 12, organisée par AMD et Nvidia, c'est ce dernier qui s'est chargé de présenter la partie multi-GPU et de distiller des conseils d'utilisation réalistes pour le nouveau mode explicite. Les combinaisons exotiques laissées de côté, c'est le frame pipelining sur base d'une configuration de GPU identiques qui est mis en avant.

L'an passé, Microsoft a annoncé avoir intégré à DirectX 12 un support explicite très flexible pour le multi-GPU. Pour rappel, la nouvelle API conserve tout d'abord un mode implicite, similaire au SLI et CrossFire sous DirectX 11. Avec ce mode les pilotes sont censés se charger en toute transparence de donner vie au multi-GPU via le mode AFR.

Mais comme l'explique Nvidia, entre la théorie et la pratique il y a un gouffre et dans de plus en plus de cas le multi-GPU ne fonctionne pas, ou avec de très faibles performances, notamment quand des techniques de rendu dites "temporelles" sont exploitées. Celles-ci englobent toute approche qui a besoin de données issues d'images précédentes pour en calculer une nouvelle, par exemple certains filtres d'antialiasing. Vu que ces images précédentes ont été calculées par un autre GPU, ces données ne sont pas facilement accessibles.

Pour résoudre ce type de problème, et bien d'autres, DirectX 12 supporte une gestion explicite du multi-GPU. Cette fois il ne fonctionne plus automatiquement et il revient aux développeurs de prévoir leur moteur pour qu'il prenne conscience du nombre de GPU et les contrôle explicitement. Plusieurs possibilités existent alors.

Celle qui a fait le plus parler d'elle est le mode explicite non-lié (unlinked) qui permet d'associer tout type de GPU, de marques différentes, de génération différente et de niveau de performances différent. C'est le mode qu'a choisi d'implémenter Oxide dans Ashes of the Singularity, probablement pour pousser le plus loin possible ses expérimentations avec la nouvelle API, mais ce n'est pas celui qui va intéresser la majorité des développeurs, celui-ci impliquant la prise en compte de trop nombreuses combinaisons. Le multi-GPU est une niche du marché PC, ce qui implique que ce n'est pas sur ce point que les développeurs veulent investir le plus de temps en implémentation et en validation.

Reste alors le mode explicite à noeud lié (linked node), un noeud représentant un ensemble de GPU activé au niveau des pilotes. Autant AMD que Nvidia exposent un tel noeud dès que le CrossFire ou le SLI sont enclenchés dans leurs panneaux de contrôle. Attention, cela ne veut pas dire que le multi-GPU fonctionnera automatiquement ! Tout le contrôle reste dans les mains des développeurs mais ils ont alors l'assurance d'avoir affaire à des GPU identiques ou similaires, ce qui simplifie leur travail. Tout du moins pour le moment puisqu'il n'est pas impensable qu'AMD et Nvidia autorisent des noeuds hétérogènes dans le futur.

Ce mode explicite lié donne également accès à un lien dédié éventuel, soit au point SLI dans le cas des GPU Nvidia, AMD ayant abandonné le lien CrossFire au profit exclusif du PCI Express. Cet accès spécial n'est cependant exploité que si le multi-GPU implémenté est de type AFR. Le reste des transferts se fait via le bus PCI Express mais directement de GPU à GPU.

Les développeurs pilotent le multi-GPU à travers le multi engine, cette même fonctionnalité présente au coeur de DirectX 12 et qui permet de booster les performances à travers l'exécution concomitante de files de commandes (Async Compute). Il suffit de dédoubler la ou les files de commandes pour alimenter deux GPU.

D'ailleurs, pour maximiser les performances, il est important d'avoir recours à une file dédiée de type copy pour organiser les transferts entre GPU. De quoi effectuer ces opérations en parallèle du rendu 3D et en masquer le coût. Si les GPU Nvidia ont du mal avec les files graphics et compute, ils n'ont par contre pas de problème pour traiter simultanément des files graphics et copy, tout du moins dans le cas des GPU Maxwell 2 qui disposent de deux moteurs de transferts DMA. A ce point, nous ne savons pas si les GPU précédents qui s'en contentent d'un seul pourraient être affectés.

Nvidia rappelle ensuite qu'il existe différents tiers pour le partage de ressources à l'intérieur d'un noeud. Ce niveau de support est exposé à travers D3D12_CROSS_NODE_SHARING_TIER. Deux niveaux sont possibles : le tiers 1 ne supporte que les copies entre GPU alors que le tiers 2 autorise les accès à certaines ressources présentes dans la mémoire d'un autre GPU. Un dernier mode, le tiers 1 émulé est également proposé et consiste à implémenter dans les pilotes un mécanisme de transfert lorsque la copie directe de GPU à GPU n'est pas supportée.

Nous avons vérifié rapidement quel était le niveau de support proposé par AMD et Nvidia. Sur les GeForce Maxwell 2 il est de type tiers 2 alors qu'AMD se contente du tiers 1 sur GCN 1.1 et 1.2 (Hawaii et Fiji). Nvidia précise cependant que si les accès autorisés par le tiers 2 peuvent sembler pratiques, dans bien des cas il sera plus efficace d'effectuer une copie complète et de se contenter des fonctions du tiers 1.

Si exploiter le mode explicite lié peut permettre de faire de l'AFR (alternate frame rendering) avec un peu plus de flexibilité qu'en mode implicite, son intérêt réside surtout dans la possibilité d'implémenter d'autres modes de rendu, notamment pour résoudre les problèmes liés aux techniques qui font appel à une composante temporelle.

 
 

La solution à ces problème est appelée frame pipelining par Nvidia. Elle consiste à débuter le rendu d'une image sur un GPU et à transférer ces premiers éléments au second GPU en vue de la finalisation du rendu. Les GPU et leurs moteurs de copies travaillent alors à la chaine, d'où le nom de cette approche. Il est alors possible de prendre en charge sans problème un antialiasing temporel par exemple.

Pour mettre en place le frame pipelining, il faut parvenir à scinder son rendu en deux phases qui représentent une charge à peu près similaire et à un niveau qui permette de limiter les données à transférer. Il ne faut en effet pas oublier qu'un transfert de 64 Mo à travers un bus PCIe 3.0 8x prend au moins 8 ms, en général un peu plus en pratique. Pour éviter de transférer trop de données il peut alors être censé de dédoubler sur chaque GPU le calcul de certains éléments.

 
 

Dans l'exemple pris par Nvidia, le bi-GPU implémenté via le frame pipelining permet à la base de passer de 22 à 31 fps (+41%) et de monter à 37 fps (+68%) en exploitant le copy engine. Cet exemple est cependant un stress test en haute résolution (2160p) qui implique le transfert de la shadow map, du depth buffer et du SSAO, ce qui représente 87.3 Mo et prend à peu près 15 ms en PCIe 3.0 8x. Un temps de transfert qui limite le nombre de fps à +/- 60.

Le problème restant avec cette approche concerne la latence qui augmente à peu près comme en mode AFR. Le GPU1 effectue tout son travail, les données sont transférées puis le GPU effectue son travail. A 60 fps, et par rapport à un gros GPU de puissance équivalente, cela implique un triplement de la latence (de 16.7 ms à près de 50 ms). Heureusement, la partie liée au transfert de cette latence supplémentaire peut être masquée, exactement comme le fait Oxide pour le mode Async Compute d'AotS. Il suffit de décomposer le rendu en plus petits groupes de commandes et de transférer progressivement les éléments entre les GPU à travers le copy engine.

Reste bien entendu à voir ce que feront les développeurs de tout cela et à quel point AMD et Nvidia pourront les aider. Même si implémenter le frame pipelining en prenant en compte uniquement des ensembles de GPU similaires est plus simple que d'autres modes de rendus avec des combinaisons exotiques, cela représente un travail supplémentaire que tous n'accepteront probablement pas de prendre en charge. Et nous ne parlons mêmes pas des modes tri-GPU et quadri-GPU dont le support exigerait des développements complémentaires spécifiques…

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

 
 

GDC: Async Compute : ce qu'en dit Nvidia

Publié le 23/03/2016 à 18:31 par Damien Triolet

Nous avons bien entendu profité de la GDC pour questionner Nvidia en vue d'en apprendre plus sur ce dont sont capables ses GPU en terme de prise en charge du multi engine de DirectX 12… sans réel succès ?

Au coeur de DirectX 12, cette fonctionnalité permet de décomposer le rendu en plusieurs files de commandes, qui peuvent être de type copy, compute ou graphics, et de gérer la synchronisation entre ces files. De quoi permettre aux développeurs de prendre le contrôle sur l'ordre dans lequel les tâches sont exécutées ou encore de piloter directement le multi-GPU. Cette décomposition permet également dans certains cas de profiter de la capacité des GPU à traiter plusieurs tâches en parallèle pour booster les performances.


Illustration du Multi Engine de DirectX 12, qui permet de traiter plusieurs files de commandes en parallèle.

C'est ce qu'AMD appelle Async Compute, bien que le terme ne soit pas correct. En effet, l'exécution asynchrone d'une tâche n'implique pas qu'elle soit traitée en concomitance d'une autre, or c'est ce dernier point qui est crucial et permet un gain de performances. Les GPU AMD profitent de multiples processeurs de commandes capables d'alimenter les unités de calcul du GPU à partir de plusieurs files différentes. Un traitement en simultané des tâches qui permet de maximiser l'utilisation de toutes les ressources du GPU : unités de calcul, bande passante mémoire etc.

Du côté de Nvidia c'est plus compliqué. Si les GeForce sont capables de prendre en charge les files copy en parallèle des files compute et graphics, traiter ces deux dernières en concomitance semble poser problème. Théoriquement les GPU Maxwell 2 (GTX 900) disposent d'un processeur de commandes capables de prendre en charge 32 files dont une peut être de type graphics. Et pourtant ce support n'est toujours pas fonctionnel en pratique, comme le démontrent par exemple les performances des GeForce dans Ashes of the Singularity.

Pourquoi ? Jusqu'ici, nous n'avons pu obtenir de réelle réponse de Nvidia. Alors bien entendu nous avons voulu profiter de la GDC pour tenter d'en savoir plus et avons questionné Nvidia lors d'un meeting organisé avec Rev Lebaredian, Senior Director GameWorks. Malheureusement pour nous, cet ingénieur qui fait partie du groupe de support technique aux développeurs de jeux vidéo avait été très bien préparé à ces questions qui concernent les spécificités du support du multi engine. Ses réponses ont au départ été mot pour mot celles de la brève déclaration officielle de Nvidia communiquée à la presse technique depuis quelques mois. A savoir "les GeForce Maxwell peuvent prendre en charge l'exécution en concomitance au niveau des SM (groupes d'unités de calcul)", "ce n'est pas encore actif dans les pilotes", "Ashes of the Singularity n'est qu'un seul jeu (pas trop important) parmi d'autres".

Une langue de bois inhabituelle qui démontre, si cela était encore nécessaire, que cette question dérange chez Nvidia. Nous avons donc changé d'approche et pour sortir de l'impasse nous avons abordé le sujet sous un angle différent : est-ce que l'Async Compute est important (pour les GPU Maxwell) ? De quoi détendre Rev Lebaredian et ouvrir la voie à une discussion bien plus intéressante. Deux arguments sont alors avancés par Nvidia.

D'une part, si Async Compute est un moyen d'augmenter les performances, ce qui compte au final ce sont les performances globales. Si les GPU GeForce sont à la base plus performants que les GPU Radeon, le recours au multi engine pour tenter de booster leurs performances n'est pas une priorité absolue.

D'autre part, si le taux d'utilisation des différents blocs des GPU GeForce est relativement élevé à la base, le gain potentiel lié à Async Compute est moins important. Nvidia précise sur ce point que globalement il y a beaucoup moins de trous (bubbles en langage GPU) au niveau de l'activité des unités de ses GPU que chez son concurrent. Or le but de l'exécution concomitante est d'exploiter une synergie dans le traitement de différentes tâches pour remplir ces "trous".

Derrière ces deux arguments avancés par Nvidia se cachent en fait celui de la bonne planification d'une architecture GPU. Intégrer dans les puces un ou des processeurs de commandes plus évolué a un coût, un coût qui peut par exemple être exploité différemment pour proposer plus d'unités de calcul et booster les performances directement et dans un maximum de jeux.

Lors du développement d'une architecture GPU, une bonne partie du travail consiste à prévoir le profil des tâches qui seront prises en charge quand les nouvelles puces seront commercialisées. L'équilibre de l'architecture entre ses différents types d'unités, entre la puissance de calcul et la bande passante mémoire, entre le débit de triangles et le débit de pixels, etc., est un point crucial qui demande une bonne visibilité, beaucoup de pragmatisme et une vision stratégique. Force est de constater que Nvidia s'en tire plutôt bien à ce niveau depuis quelques générations de GPU.

Pour illustrer cela, faisons quelques petites comparaisons entre le GM200 et Fiji sur base des résultats obtenus dans Ashes of the Singularity sans Async Compute. La comparaison est grossière et approximative (le GM200 exploité est tiré de la GTX 980 Ti qui en exploite une version légèrement castrée), mais reste intéressante :

  • GM200 (GTX 980 Ti) : 6.0 fps / Gtransistors, 7.8 fps / Tflops, 142.1 fps / To/s
  • Fiji (R9 Fury X) : 5.6 fps / Gtransistors, 5.8 fps / Tflops, 97.9 fps / To/s

Nous pourrions faire de même avec de nombreux jeux et le résultat serait similaire, voire encore plus marqué (AotS est particulièrement efficace sur Radeon) : le GM200 exploite mieux les ressources à sa disposition que Fiji. C'est un choix d'architecture, ce qui n'implique pas directement qu'il est meilleur qu'un autre. Augmenter le rendement de certaines unités peut avoir un coût supérieur à l'augmentation de leur nombre dans une mesure plus importante. Le travail des architectes consiste à trouver le meilleur équilibre à ce niveau.

De toute évidence, AMD a plutôt misé sur les débits bruts de ses GPU, ce qui implique en général un rendement inférieur et plus d'opportunité d'optimisation au niveau de celui-ci. Ajoutez à cela que l'organisation de l'Async Compute dans AotS semble plutôt optimiser l'utilisation du surplus de bande passante mémoire et vous comprendrez aisément qu'il y a moins à gagner du côté de Nvidia. D'autant plus que les commandes de synchronisation liées à Async Compute ont un coût qui ne sera masqué que par un gain significatif.

Si notre propre réflexion nous amène à être plutôt d'accord avec ces arguments de Nvidia, il reste un autre point important pour les joueurs et c'est probablement ce qui fait que le numéro un du GPU aborde le sujet du bout des lèvres : Async Compute apporte un gain gratuit aux utilisateurs de Radeon. Alors que cette possibilité a été prévue dans les GPU AMD depuis plus de 4 ans, ils n'ont pas pu en tirer un bénéfice commercial, ils n'ont pas été vendus plus chers pour la cause. Cela change quelque peu avec la dernière gamme d'AMD qui mise fortement sur ce point, mais, en terme de perception, les joueurs apprécient d'obtenir gratuitement un tel petit coup de boost, même s'il ne concerne qu'une poignée de jeux. A l'inverse, le rendement globalement plus élevé des GPU Nvidia a pu avoir un bénéfice immédiat dans un maximum de jeux, et a pu être pris en compte directement dans le tarif des GeForce. Et du point de vue d'une société dont le but n'est pas d'afficher des pertes, il est évident qu'une approche a plus de sens qu'une autre.

Reste que nous sommes en 2016 et que l'exploitation de l'Async Compute devrait progressivement se généraliser, notamment grâce à la similitude entre l'architecture des GPU des consoles et celle des Radeon. Nvidia ne peut donc pas totalement ignorer cette possibilité qui pourrait réduire voire supprimer son avance en termes de performances. Sans rentrer dans le moindre détail, Rev Lebaredian a ainsi tenu à réaffirmer qu'il y avait bel et bien des possibilités au niveau des pilotes pour implémenter un support qui permette de profiter dans certains cas d'un gain de performances avec l'Async Compute. Des possibilités que Nvidia réévalue en permanence, non sans oublier que ses futurs GPU pourraient changer la donne à ce niveau.

GDC: Async Compute et AotS : des détails

Publié le 21/03/2016 à 14:54 par Damien Triolet

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 :

 
 

GDC: Autre exemple DX12 avec Quantum Break

Publié le 16/03/2016 à 05:18 par Damien Triolet

Après un premier exemple de portage DirectX 12 avec Hitman, nous avons pu assister à une seconde session présentée par Remedy au sujet de Quantum Break dont le moteur Northlight est également passé à la nouvelle API de Microsoft. Une présentation qui pourrait être résumée par "tout ça pour ça"…

 
 

Bien que Quantum Break soit annoncé comme une exclusivité Windows et DirectX 12 sur PC, le moteur Northlight est une évolution du moteur maison introduit avec Alan Wake qui à sa base supporte bien DirectX 11. C'est cette base DirectX 11 qui a été portée vers DirectX 12 tout d'abord sur Xbox One, ce qui a représenté le plus gros du travail, et ensuite sous Windows 10. Remedy insiste bien sur le fait qu'il ne s'agit pas d'une réécriture complète et qu'il y a donc encore pas mal de marge pour mieux profiter de la nouvelle API.

S'il y a un point sur lequel Remedy a insisté c'est sur la difficulté que représente l'optimisation des performances au niveau du GPU avec DirectX 12. Parvenir à égaler les performances GPU obtenues sous DirectX 11 demande beaucoup de travail. Comme nous l'avons expliqué plusieurs fois, les drivers AMD et Nvidia bénéficient de plusieurs années d'optimisations et autres astuces dédiées à maximiser les performances GPU. Pas simple de faire de même pour les développeurs de jeux vidéo. Plutôt réaliste face à cette tâche, Remedy est ainsi plutôt satisfait d'avoir pu égaler les performances DirectX 11 pour les GPU Maxwell ainsi que pour les Radeon.

Concernant les performances CPU, la situation est totalement différente et DirectX 12 permet d'obtenir des gains assez facilement. Reste que tous les jeux ne sont pas limités par le surcoût des commandes de rendu. S'ils peuvent se contenter d'un nombre réduit pour ces dernières à travers une organisation efficace du rendu, il n'y a pas réellement de gain important à aller chercher. Pour Quantum Break, c'est ainsi un petit gain de 5 à 10% qui a été obtenu.

Un tel travail de développement pour si peu de bénéfices a de quoi soulever des questions, mais pour Remedy il s'agit d'une première expérience avec DirectX 12, d'une phase d'apprentissage nécessaire. Et d'un bon moyen pour Microsoft de pousser les joueurs à migrer vers Windows 10.

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

 
 

GDC: Hitman et le portage DirectX 12

Publié le 15/03/2016 à 17:35 par Damien Triolet

Lors de la première journée de GDC, la tradition veut qu'AMD et Nvidia s'associent pour organiser un ensemble de tutoriels à destination des développeurs. Cette année, comme vous pouvez vous en douter, ils portaient tous sur Direct3D 12 et quelques développeurs sont venus faire part de leur première expérience avec cette nouvelle API. C'est le cas d'IO Interactive qui nous a parlé d'Hitman, à travers Jonas Meyer, responsable du rendu du moteur Glacier.

 
 

Hitman et le moteur Glacier reposent sur un rendu de type Tile Deferred qui lui permet de prendre en charge un nombre très élevé de sources de lumière. Le principe consiste à subdiviser l'image en petits blocs, les light tiles, et à déterminer par quelles sources de lumière chacun d'entre eux est réellement affecté. Un tri qui évite le calcul prohibitif de chaque source de lumière pour chaque pixel.

IO Interactive a décidé de porter ce moteur sous Direct3D 12, mais pas d'en faire une réécriture complète. La base du moteur repose toujours sur Direct3D 11. L'objectif de ce portage était d'améliorer les performances d'une part du côté CPU et d'autre part du côté GPU à travers l'exploitation d'async compute (multi engine).

Mais les développeurs ont tout d'abord été particulièrement surpris par un autre point : le temps de travail requis pour mettre en place une gestion de la mémoire efficace pour éviter d'en gaspiller et pour assurer un code robuste. Avec les nouvelles API, ce n'est plus le pilote qui se charge automatiquement de tout cela et de nombreux problèmes peuvent se poser. Il est donc crucial de contrôler en permanence l'utilisation de la mémoire sans quoi c'est l'OS qui va prendre la main pour faire de la place sans ménagement, ce qui peut conduire à un plantage, notamment lorsque l'on passe d'une application à l'autre.

Les pilotes ont la possibilité de marquer certaines ressources comme prioritaires (par exemple les render targets), ce qui aide dans bien des cas, mais d'autres types de ressources peuvent être cruciales. Actuellement les développeurs n'ont aucun moyen de les marquer comme prioritaires et pour garantir la robustesse de leur code ils doivent donc s'assurer que l'utilisation globale de la mémoire reste dans les clous. Pouvoir spécifier manuellement quelles ressources sont prioritaires est une future évolution souhaitée par IO Interactive.

 
 

Une fois ces difficultés surmontées, les développeurs ont pu se concentrer sur l'aspect performances avec tout d'abord des gains significatifs au niveau du CPU. Du côté GPU, l'async compute a été implémenté de manière relativement basique avec la mise en parallèle du calcul du SSSAA (filtre d'antialiasing), du SSAO (occultation ambiante) et des light tiles. De quoi obtenir un gain de 5 à 10% sur les Radeon mais nul pour les GeForce. IO Interactive précise à ce sujet être en train de travailler avec Nvidia pour essayer d'améliorer cela.

Pour terminer, une comparaison des performances entre Direct3D 11 et 12 a été présentée pour deux GPU différents. Si IO Interactive ne précise pas de quel GPU il s'agit, il semble évident qu'il s'agit dans le premier cas d'un GPU Nvidia et dans le second cas d'un GPU AMD qui profite de gains bien plus importants.

 
 

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

 
 

Top articles