Polaris 10 : GCN 4

Les GPU Polaris sont basés sur l'architecture GCN introduite par le GPU Tahiti et la Radeon HD 7970 fin 2011. AMD n'a pas opéré de changement majeur d'architecture depuis, contrairement à Nvidia qui est passé de Fermi à Kepler puis à Maxwell à laquelle Pascal est similaire. Par contre de petites améliorations ont progressivement été apportées.

Au départ, AMD ne proposait aucune nomenclature simple pour faire référence à ces améliorations de l'architecture. Nous avions donc pris l'initiative de parler de GCN 1.0, 1.1 et 1.2. Depuis quelques temps, AMD a réalisé que c'était devenu un problème et parler dorénavant de GCN de 1ère génération, de 2ème génération, de 3ème génération etc. Nous allons donc reprendre cette manière de présentation les choses et parler de GCN 1, GCN 2, GCN 3 et GCN 4 pour les nouveaux GPU Polaris.

Les GPU GCN 2 (Hawaii et Bonaire) ont apporté entre autre le support du niveau 12_0 de DirectX 12, de TrueAudio, de FreeSync ou encore de la HSA. De leur côté, les GPU GCN 3 (Fiji et Tonga) ont intégré le codage différentiel, amélioré les processeurs de commandes pour le calcul asynchrone et intégré le support d'opérations en démi précision (FP16/INT16). Et bien entendu les GPU GCN 4 apportent également plusieurs petites nouveautés donc certaines présentes sur cette liste sont cependant des mises à jour logicielles qui seront répercutées sur d'autres GPU.

 

 

Quelques petites optimisations ont tout d'abord été apportées aux Compute Units (CU), ces blocs de base de l'architecture à peu près équivalents aux SM de Nvidia. Ils restent composés de 4 SIMD 16-way (64 unités de calcul) associés à un fichier registre de 256 Ko et à une mémoire partagée de 64 Ko. Ils englobent également 4 unités de texturing avec leur cache L1 de 16 Ko. Une structure qui n'a pas bougé depuis le premier GPU GCN.

Pour augmenter le rendement des CU, AMD a mis en place un prefetch plus efficaces pour les instructions et élargi le buffer qui leur est dédié. Les accès au cache L2 ont également été optimisés, notamment avec plus d'opportunités de regroupement de ces accès.

AMD mentionne également le support natif de la demi précision tant sur les flottants (FP16) que sur les entiers (INT16). Ce support est cependant déjà présent depuis GCN 3 (pas uniquement les APU comme le laisse penser le tableau) et nous ne savons pas pourquoi il est mentionné ici comme nouveauté. Questionné à ce sujet, AMD nous a répondu qu'il n'y avait en fait "probablement" pas de différence à ce niveau avec GCN 4.

Ce support natif ne se traduit pas par une puissance de calcul doublée comme le fait Nvidia avec le GP100 ou comme le font certains GPU mobiles. Les opérations FP16 seront par exemple traitées par les unités FP32 à la même vitesse que les opérations FP32, mais elles auront l'avantage d'économiser de l'espace dans le fichier registre et de réduire les déplacements de données, coûteux en énergie.

Au final, AMD annonce un gain de performances par CU, à fréquence égale, qui peut monter jusqu'à 15% entre GCN 4 et GCN 2.

Le support de cette demi-précision est exposé dans DirectX depuis quelques temps déjà mais à notre connaissance aucun jeu n'y fait appel. Il y a donc probablement des possibilités d'optimisation encore inexploitées à ce niveau, mais qui sont également valides pour certains anciens GPU.

A noter à ce sujet qu'AMD propose depuis peu le support de fonctions intrinsèques dans DirectX 11, DirectX 12 et Vulkan. Il s'agit de morceaux de code ASM hyper optimisé qui peuvent se substituer à l'appel d'une fonction équivalente mais qui ne pourrait pas être aussi efficace. Par exemple, si un développeur a optimisé à la main un shader important sur console, il pourra également l'exploiter sur PC. Nous suspectons Nvidia d'en faire même pour certains effets GameWorks par exemple, dont le code universel est probablement remplacé par les pilotes par une version plus finement optimisée.

AMD a ensuite améliore les processeurs géométriques des GPU GCN 4. Au départ nous pensions qu'AMD cherchait à augmenter le débit d'éjection des triangles hors champs de vision (frustum culling) ou qui tournent le dos à la caméra (backface culling) mais il n'en est rien. Le Primitive Discard Accelerator (PDA) qui fait son apparition n'est pas destiné à augmenter le débit maximal mais plutôt à permettre de s'en rapprocher dans certains cas difficiles.

Il est dédié à éjecter les triangles qui représentent moins d'un pixel à l'écran (ou sample dans le cas du MSAA). Cela peut se présenter avec un niveau extrême de tessellation qui va revenir à générer bien plus de primitives (triangles en général) que la résolution ne permet d'en afficher. Le problème est que ces primitives sont accompagnées de toute une série de paramètres qui peuvent prendre beaucoup de place dans les buffers. De quoi les saturer et mettre le GPU à genoux. Le rôle du PDA est d'éjecter ces primitives directement après toutes les opérations sur les vertices (vertex shader, hull shader, domaine shader, geometry shader) pour éviter d'embouteiller les buffers avant la rastérisation.

Avec MSAA et un niveau de tessellation extrême les performances peuvent être triplées. Reste qu'en principe les développeurs essayent d'éviter de se retrouver dans cette situation. Il s'agit probablement d'une "protection anti-GameWorks" pour éviter que les performances ne soient massacrées sur les Radeon si Nvidia décidait de forcer un peu trop sur le niveau de tessellation de certains de ses effets. Nous n'avons noté aucun gain dans nos tests théoriques qui ne se placent pas dans ce cas de figure.

 

 

Enfin, il y a du neuf au niveau de l'exécution asynchrone et concomitante des tâches. En plus de l'exécution concomitante (2 tâches traitées en même temps) et de la préemption (une tâche est mise en pause pour en traitre une plus urgente), AMD a mise en place un troisième mode appelé Quick Response Queue ou file de réaction rapide. Il s'agit cette fois de donner une priorité supérieure à certains tâches de type compute pour qu'elles soient exécutées en parallèles des autres tâches mais en se voyant attribuer plus de ressources.

C'est l'approche qui est utilisée pour le time warping par le SDK LiquidVR et qui sera dorénavant exposée dans les API telles que DirectX 12 et Vulkan. A noter que cette possibilité sera également rendue disponible sur les GPU GCN 3. Les processeurs de commandes flexibles de l'architecture des GPU GCN offrent de nombreuses possibilités de ce type et leurs fonctionnalités en pratique dépendent en grande partie de l'implémentation logicielle.

Polaris et affichage

Comme nous vous l'avons déjà expliqué, tout cela a été annoncé par AMD en janvier, les GPU Polaris profitent d'un moteur d'affichage qui a été mis à jour pour supporter le HDMI 2.0b et les futurs DisplayPort 1.3 et 1.4.

 

 

Les GPU Polaris apportent enfin le support du HDM 2.0b nécessaire pour pouvoir jouer sur une TV en 4K 60 Hz. Un support qui inclus le HDCP 2.2 requis pour afficher les Blu-Ray UHD et certaines vidéos 4K diffusées en streaming.

Bien que ce support ne soit pas encore fonctionnel, il en va de même pour les GPU Pascal, les GPU Polaris sont prêts pour le DisplayPort 1.3 ainsi que pour le DisplayPort 1.4. Le premier apporte le mode HBR3 qui pousse la bande passante à 32.4 Gbps, 80% de plus que pour le HDMI 2.0b. De quoi pouvoir supporter des écrans 4K 120 Hz ou 5K 60 Hz avec un seul câble.

Le DP 1.4 autorise l'utilisation des formats HDR, jusqu'à 96 Hz pour le 10-bit en 4K ou encore jusqu'à 200 Hz pour le 10-bit en 1440p. Un format qui pourrait avoir du succès chez les joueurs quand les écrans débarqueront. Les Radeon R300 et probablement toutes les cartes GCN, supporteront également la HDR via une mise à jour des pilotes mais seront limitées à au 1440p 60 Hz ou à la 4K 30 Hz.

 

 

Rappelons que le HDR ou High Dynamic Range permet d'afficher des images plus lumineuses, avec des couleurs plus fidèles. Comme vous le savez probablement, les jeux récents sont en général rendus en HDR avant qu'un algorithme de tone mapping transforme le tout en une image SDR affichable par nos écrans classiques. Ce n'est bien entendu pas idéal mais faute de mieux cela permettait de bénéficier en partie des avantages du HDR.

Cela va changer avec l'arrivée progressive de TV et de moniteurs capables d'afficher directement des images HDR, plus fidèles et plus vives. Pour cela ces écrans devront proposer une luminosité supérieure (de 1000 à 2000 cd/m² pour les LCD et de 500 à 1000 cd/m² pour les OLED) et supporter un espace de couleurs étendu (BT.2020) avec un encodage 10-bit ou 12-bit adapté à ces nouvelles capacités (ST 2084 PQ). Les Radeon Polaris supportent autant le 10-bit que le 12-bit, mais dans un premier temps nous ne devrions voir débarquer que des écrans 10-bit.

AMD propose dès à présent le Photon SDK aux développeurs. Il est dédié à faciliter l'intégration par les moteurs de jeu d'un algorithme de tone mapping adapté avec un mécanisme capable d'en déterminer la bonne configuration sur base des paramètres spécifiques de chaque écran. Un pilote HDR pour DirectX 11 est actuellement fourni à ces mêmes développeurs et la version DirectX 12 suivra d'ici quelques temps. Le support de la lecture des vidéo HDR est également actif dans ces pilotes destinés aux développeurs.

AMD précise que la collaboration de Microsoft sera également nécessaire pour profiter pleinement du HDR, Windows 10 n'étant actuellement pas compatible. Il est possible de passer outre la gestion des couleurs de Windows en mode plein écran exclusif, mais une mise à jour de son sous-système graphique sera nécessaire pour pouvoir combiner correctement des contenus HDR et SDR.

Polaris et moteurs vidéo

AMD a mis à jour ses moteurs vidéo tant au niveau du décodage (UVD) que de l'encodage (VCE).

 

 

En plus des formats H.264 1080p60, VC1 1080p60 et MP4-P2 1080p60 supportés depuis les premiers GPU GCN, les GPU Polaris supportent le H.264 jusqu'en 4K120, comme les GPU GCN 3, et HEVC Main Profile 4K60 comme le GPU Fiji. Ils y ajoutent le HEVC Main 10 4K60, le MJPEG 4K30 ainsi que le VP9 en 4K à un niveau encore indéterminé, son support dans les pilotes n'ayant pas encore été implémenté.

 

 

Au niveau de l'encodage en H.264, les GPU Polaris sont similaires au GPU Fiji et supportent du 1080p120, du 1440p60 et de la 4K30. Etrangement ils ne supportent pas la 4K60 pourtant bien fonctionnelle sur le GPU Tonga. Les GPU Polaris apportent par contre le support de l'encodage HEVC jusqu'au 1080p240, 1440p120 et 4K60.

Autre nouveauté pour les GPU Polaris, un nouvel algorithme sera proposé pour l'encodage destiné au streaming. Il permet d'améliorer la qualité avec un gain Y-PSNR de 1 dB en ayant recours à 2 passes, que ce soit en H.264 ou en HEVC.