Les derniers contenus liés aux tags AMD et GDC

Microsoft a profité de l'ouverture de la GDC pour annoncer une nouvelle API, DirectX Raytracing (DXR) . Comme son nom l'indique, il s'agit d'une nouvelle API qui vient s'ajouter aux autres API DirectX pour standardiser l'utilisation de certaines techniques dites de raytracing. Le raytracing tente pour rappel de représenter de manière plus exacte le parcours de la lumière pour proposer des rendus réalistes. L'inconvénient de la technique étant son coût généralement prohibitif, même si des approximations existent.

A l'inverse, le rendu 3D dans les jeux actuel est basé sur la rasterisation, la projection d'une scène 3D en 2D avant d'y appliquer les traitements pour obtenir la couleur des pixels, avec des techniques plus ou moins avancées de gestion de lumière (les premiers jeux 3D se contentant d'imiter les effets de lumière en les dessinant directement dans les textures, tandis qu'aujourd'hui les pixel shaders s'appliquent sur l'image 2D ce qui limite les possibilités même si les développeurs sont extrêmement créatifs). Comme le rappelle le sous titre de l'annonce de Microsoft, "3D Graphics is a lie" (le rendu 3D est un mensonge) !

Avec DXR, Microsoft souhaite donc ajouter un peu de "réalisme" avec une petite dose de raytracing. Dans le détail, il s'agit d'une API complémentaire qui ajoute de nouvelles possibilités pour utiliser le raytracing par dessus les pipelines actuels de rasterisation. En pratique, DXR s'appuie sur une représentation de la géométrie pour lancer des rayons. Par dessus cette représentation, chaque objet ou groupe d'objet pourra définir des "raytracing shaders" et des textures spécifiques à utiliser. Une fois ceci crée, le lancé de rayons est appliqué, l'API définie les cas d'intersection, de non intersection, et de "presque" intersection (near miss), en gérant les cas ou les rayons rebondissent sur plusieurs surfaces (multi bounce).

Techniquement, le lancer de rayon est effectué a partir de la "caméra" dans la variante utilisée par DirectX, et peut se faire pour une sélection de pixels de l'écran ou la totalité (Microsoft prend l'exemple de ne le faire uniquement que pour les objets dont la surface est réfléchissante).

Un exemple de rendu DXR avec le moteur SEED d'EA, Project PICA

D'un point de vue compatibilité avec le matériel existant, Microsoft renvoi simplement vers les constructeurs pour les détails. Certains matériels sur le marché disposeraient déjà d'un support de DXR (on ne sait pas lesquels), et Microsoft semble proposer un mode de rendu alternatif s'appuyant sur Direct Compute pour fonctionner sur tout le matériel existant aujourd'hui (avec un niveau de performances on l'imagine réduit).

AMD nous a indiqué qu'ils collaboraient "étroitement" avec Microsoft "pour les aider à définir, améliorer et prendre en charge l'avenir de DirectX 12 et du ray tracing", un propos qui évite soigneusement de prononcer l'acronyme DXR. AMD dispose déjà d'une API de ce type utilisable sur de multiples plateformes avec Radeon Rays . Interrogé sur la question spécifique de l'accélération matérielle, AMD nous a indiqué qu'ils proposeraient, à un moment non défini, un pilote qui proposera une accélération DXR (au delà du mode "fallback" utilisant Direct Compute et qui lui marche sur tous les GPU, mais probablement en étant peu utilisable). Ce qui sera accéléré, et quelles cartes seront concernées n'est pas encore défini non plus selon le constructeur. On semble sentir une certaine précaution pour ne pas dire frilosité de la part de la société sur sa communication, il nous est difficile de savoir s'il s'agit d'un manque de préparation sur le sujet, d'un désaccord avec Microsoft sur certains choix effectués, ou d'autre chose.

Nvidia de son côté a évoqué son implémentation sous le nom de RTX, cette dernière ne s'appliquera qu'à compter des GPU Volta et ultérieurs (soit uniquement la Titan V dans les GPU "joueurs" actuels de la gamme du constructeur). Nvidia présente la technologie là aussi de manière assez vague, sous entendant que leur implémentation sera utilisable "via" DXR, mettant son API en avant sans que l'on sache si c'est simplement dans un but de démarcation compétitive ou autre chose. Là encore à l'image d'AMD, la communication des deux principaux constructeurs ne va pas exactement dans le même sens que celle de Microsoft (les relations entre Microsoft et les responsables GPU ont toujours été particulières, chacun tentant de tirer la couverture de son côté et de créer un avantage compétitif, que ce soit les constructeurs de GPU l'un face à l'autre, ou Microsoft à proposer une API et des fonctionnalités qui ne soient pas cross-platform).

Du côté des développeurs, Microsoft annonce que les moteurs Frostbite, SEED (plus haut), Unity et Unreal Engine proposeront une forme de support de DXR. Futuremark devrait également proposer un test de ce type pour une version de 3D Mark.

Lors de la GDC, AMD n'a pas dévoilé de nouvelles informations techniques concernant sa future architecture et son futur GPU Vega 10. Mais à côté d'une démonstration du FP16 et du HBCC, le nom commercial des Radeon basées sur ce futur GPU haut de gamme a été dévoilé : ce sera tout simplement Radeon RX Vega.

AMD compte profiter de toute la communication qui a déjà été effectuée autour de ce nom de code pour en faire une marque, ce qui est assez logique. Et il n'est pas impossible que cette marque soit dérivée en Radeon RX Vega X, Radeon RX Vega ou encore Radeon RX Vega Nano, tout cela sera précisé à l'approche du lancement de ces cartes graphiques.

Parallèlement à ces Radeon haut de gamme, AMD devrait proposer des Radeon RX 500 qui reprendront les GPU Polaris actuels et peut-être un second plus petit GPU Vega. Après une année de recul, AMD pourra probablement profiter d'une nouvelle révision, d'un procédé de fabrication en 14nm qui a gagné en maturité ou tout simplement d'un tri plus fin des puces pour proposer des fréquences en hausse et/ou une consommation en baisse.

Les Radeon RX 500 et les Radeon RX Vega sont attendues pour le second trimestre 2017.

AMD a profité de sa conférence Capsaicin organisée pendant la GDC pour effectuer de nouvelles démonstrations autour de son futur GPU Vega 10 et mettre en avant ses spécificités.

Ne vous attendez pas à un lancement d'une carte graphique à base de GPU Vega, ni a plus d'informations sur ses performances en jeu. Il est encore trop tôt pour cela, la GDC n'est pas une plateforme qui y est adaptée au vu d'un lancement plutôt attendu pour mai ou juin. Le but d'AMD est de continuer le teasing et de montrer aux développeurs ce dont est capable sa nouvelle architecture.

La première démonstration a mis en avant l'intérêt du FP16. Une précision réduite qui est pour rappel supportée pour un ensemble d'instructions exécutées avec un débit doublé par rapport au FP32 classique (grossièrement via un vecteur dans le vecteur) suivant les opportunités offertes par le code au compilateur.

AMD a développé une nouvelle version de TressFX (4.0), sa librairie de rendu et de simulation des cheveux, capable de profiter du FP16. Tout l'aspect simulation est ainsi accéléré, ce qui permet au gain global de 50% dans la démonstration de TressFX. Un gain serait également possible sur GCN 3 et GCN 4 qui ne sont pas capables d'exécuter le FP16 plus rapidement mais peuvent en profiter pour compacter les registres.

La seconde démonstration essaye de mettre en avant ce que va permettre le High Bandwidth Cache Controller de Vega. Pour rappel il s'agit d'un contrôleur mémoire plus évolué qui va pouvoir traiter la HBM ou tout autre type de mémoire comme cache local en association avec l'utilisation de mémoire système quand cela est nécessaire.

Cela nous rappelle bien entendu les promesses de l'AGP, d'HyperMemory ou encore du TurboCache. Voire même des pilotes plus intelligents censés être capables d'aider le GPU Fiji et les Radeon Fury à se contenter de 4 Go. Rien de tout cela ne nous a convaincus jusqu'ici. Mais AMD promet que cette fois avec Vega, sa solution tient la route et est réellement capable de gérer les déplacements de mémoire de manière efficace.

La première carte graphique basée sur Vega est attendue avec 8 Go de HBM2 et n'aura donc pas réellement besoin de faire appel à cette possibilité avant quelques temps. Pour démontrer cette capacité, AMD a donc limité artificiellement à 2 Go de mémoire deux cartes graphiques équipées d'un GPU Vega 10. La première utilise une gestion classique de la mémoire alors que le HBCC est actif sur la seconde. Deus Ex en mode DirectX 11 est exécuté avec un niveau de qualité adapté pour viser +/- 30 fps. Sur la première carte graphique, des saccades importantes apparaissent alors que tout est parfaitement fluide avec le HBCC. Les FPS minimaux sont presque doublés sur ce second système.

AMD ne veut pas, tout du moins pour l'instant, présenter le HBCC comme une approche qui permet de réduire les coûts en limitant la quantité de mémoire embarquée. Au contraire pour AMD, le HBCC représente une valeur ajoutées pour les joueurs, qui va permettre d'augmenter la pérennité de ses cartes graphiques qui ne verraient plus leurs performances être massacrées dès que les jeux commencent à utiliser plus de mémoire vidéo. Evidemment c'est également un point important pour positionner les cartes graphiques Vega par rapport à une éventuelle nouvelle GeForce GTX 1080 Ti qui proposerait plus de 8 Go.

Comme chaque année, la journée d'ouverture de la GDC est l'occasion pour AMD et Nvidia de s'associer pour parler des nouvelles API et aider les développeurs à mieux les exploiter. Premier sujet du jour : le wave programming qui sera introduit prochainement sous DirectX 12 et Vulkan pour permettre de nouvelles optimisations des performances.

Les nouvelles API telles que Direct3D 12 ou DirectX 12 et Vulkan permettent d'optimiser les performances à différents niveaux. Elles ont été introduites avec des promesses au niveau d'une baisse drastique du surcoût CPU lié au rendu 3D mais également avec des opportunités de gains de performances côté GPU via l'exécution concomitante de certaines tâches ("async compute"). Une nouvelle possibilité d'optimisation au niveau du GPU va bientôt être standardisée : le wave programming.

Qu'est-ce que c'est ? Fondamentalement il s'agit d'exposer le comportement vectoriel des GPU de manière à permettre aux développeurs de mettre en place des optimisations spécifiques. Jusqu'ici, pour ce qui concerne le rendu 3D, les API font une abstraction totale du modèle d'exécution vectoriel des GPU. Un vertex représente un thread, un pixel représente un autre thread et les GPU exécutent cette masse de threads comme ils l'entendent.

Comme vous le savez probablement, les unités de calcul des GPU sont en réalité de larges unités vectorielles ou SIMD qui travaillent par ailleurs sur plusieurs cycles. Du côté des GeForce ce sont des vecteurs de 32 threads (warp) qui sont pris en charge par les unités d'exécution. Du côté des Radeon les GPU GCN travaillent avec des vecteurs de 64 threads (wavefront). Idéalement tous les threads d'un warp/wavefront vont suivre un même chemin prédéfini. Mais ce n'est pas toujours le cas, il peut y avoir des divergences dans les accès mémoires et les shaders.

Exposer ce fonctionnement aux développeurs apporte de nouvelles possibilités d'optimisations au niveau du contrôle des branches, des accès mémoire ou du partage de données entre threads. Cela fait partie des optimisations qui sont accessibles pour le GPU computing et qui sont exploitées par les développeurs sur console. C'est également ce qu'AMD a commencé à mettre en place via des extensions propriétaires et autres backdoors propriétaires pour DirectX 12. AMD y faisait référence jusqu'ici en tant que fonctions intrinsèques.

Pour donner un exemple du wave programming, c'est en grande partie ce qui permet aux Radeon d'obtenir leurs très bonnes performances dans Doom. Sur le GPU GCN de la PS4, le gain est de 43% au niveau de la passe de rendu principale et une technique similaire a pu être portée sur PC. C'est également ce à quoi Nvidia fait appel pour booster les performances de certaines de ses librairies dont Optix.

Un support standardisé au niveau des shaders est en préparation pour Vulkan mais également pour DirectX 12. Microsoft travaille depuis l'an passé sur une mise à jour de son API qui va apporter les Shader Model 6. Ces SM6 seront spécifiques à Direct3D 12 mais seront compatibles avec les GPU déjà existants. Nvidia parle d'un support pour tous ses GPU depuis Kepler et AMD depuis GCN 3.

Le wave programming ne sera cependant pas simple à exploiter de manière optimale, notamment parce que les développeurs devront prévoir directement dans les fonctions de leurs shaders au moins deux cas de figure vu les différences majeures d'architectures entre AMD et Nvidia.

Pas mal d'expérimentations et de tests seront ainsi nécessaires pour s'assurer que ces optimisations apportent réellement un bénéfice sur tous les GPU. Une optimisation de ce type pour GPU AMD sera contreproductive sur GPU Nvidia ou encore pourra poser problème sur un GPU qui serait équipé de moins de registres physiques. Par contre les meilleurs développeurs pourront pousser très loin l'optimisation des shaders et c'est évidemment une bonne nouvelle pour le jeu PC.

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

 

 

La GDC 2017 ouvrira ses portes du 27 février au 3 mars, et nous aurons la chance d'y participer une nouvelle fois. En plus des sessions techniques, AMD comme Nvidia affûtent leurs armes pour des conférences marketing toutes deux prévues pour le 28 février là-bas, mais en France le 28 février à 19h30 et le 1er mars à 3h30 avec le décalage horaire.

A quelques jours de son lancement officiel, Ryzen sera probablement au centre de la conférence AMD même si on attend aussi des précisions concernant Vega. Côté Nvidia les regards se tournent vers la GTX 1080 Ti, qui pourrait être lancée à cette occasion.