Actualités informatiques du 13-11-2013

A l'occasion d'APU13, AMD vient de présenter une nouvelle roadmap autour de ses APU d'entrée de gamme. Les noms de codes avaient déjà été entrevus et la version serveur de la puce a déjà été présentées dans une précédente roadmap, les nouvelles informations sont donc relativement peu nombreuses.

Beema va succéder à Kabini pour les portables d'entrée de gamme et Mullins à Temash pour les tablettes et autres systèmes 2-en-1. Parmi les nouveautés, citons le passage de cores x86 Jaguar vers une évolution nommée Puma, à ne pas confondre avec la plateforme AMD de 2008 qui portait le même nom.


Beema et Mullins sont les premiers APU à recevoir l'AMD Security Processor qui n'est autre qu'un core Cortex-A5 intégré de manière à profiter de la plateforme de sécurisation TrustZone d'ARM. Intégrer un tel très petit core était beaucoup plus simple pour AMD que de développer sa propre plateforme pour lutter face à la Trusted Execution Technology d'Intel (TXT). Si nous supposions au départ que Kabini et Temash inaugureraient ce support, ce seront finalement Beema et Mullins.

Etrangement, AMD fait par contre l'impasse sur la HSA et Beema/Mullins ne supporteront ni la mémoire unifiée hUMA ni la gestion des tâches hQ qui resteront au départ exclusives au plus gros APU, Kaveri.


Avec Beema et Mullins, AMD met en avant une progression significative des performances par watt, qui feraient plus que doubler à process équivalent. En l'absence de détails sur leurs spécifications exactes, il est cependant difficile de savoir quel crédit donner à ces prévisions d'autant plus qu'AMD compare ici performances et TDP de Kabini 25W à Beema 15W et de Temash 8W à Mullins 4.5W.

A noter que pour Temash et Mullins, AMD ne parle plus de TDP… mais de SDP, comme le fait Intel sur ses processeurs ultra basse consommation. A titre de référence, le SDP de 3-4W de Temash correspond à un TDP de 3.9 à 9W. Pour Mullins le SDP chute à 2W, alors que le TDP d'une des variantes est de 4.5W. AMD précise cependant qu'avec Mullins il sera possible de proposer du quadcore en fanless. De quoi enfin aider AMD à se faire une petite place dans le monde des tablettes ?

Il y a un peu plus d'un an, AMD inaugurait la HSA Foundation en partenariat avec ARM, Imagination Technologies, MediaTek et Texas Instruments. Rapidement, Samsung et Qualcomm ont rejoint le groupe de fondateurs de ce consortium qui a pour rappel comme objectif de concevoir des standards dédiés au calcul hétérogène, qu'ils concernent l'aspect programmation ou l'implémentation matérielle.

Petit à petit, la liste de membres qui ont rejoint la HSA Foundation à un niveau ou à un autre s'est allongée et à l'occasion du Developer Summit 2013, AMD annonce avoir à nouveau renforcé les rangs du consortium :

Broadcom
Canonical Limited
Electronics and Telecommunications Research Institute (ETRI)
Huawei
Industrial Technology Res. Institute
Kishonti
Lawrence Livermore National Laboratory
Linaro
Oak Ridge National Laboratory
Oracle
Synopsys
TEI of Crete
UChicago Argonne, LLC. Operator of Argonne National Laboratory
VIA Technologies

Parmi les nouvelles arrivées notons le géant chinois des télécoms Huawei, Kishonti (GLBenchmark), Oak Ridge (qui a mis en place le supercalculateur Titan équipé en Tesla Kepler de Nvidia), Oracle (qui a pour rappel racheté Sun et donc Java) et VIA/S3 Graphics. De quoi donner progressivement de plus en plus d'influence à la HSA.

Son support s'étend également au niveau des langages de programmation. L'implémentation du support de la HSA est actuellement en cours pour Python, OpenMP, C++ AMP et Java :



Annoncé lors de l'AFDS de 2011 par Microsoft, C++ AMP sera, comme nous pouvions alors le supposer, étendu pour supporter la HSA en plus d'un mode OpenCL générique. La différenciation se fera au moment de la compilation où il sera possible de viser le langage intermédiaire HSAIL pour la HSA ou SPIR 1.2 pour les périphériques compatibles OpenCL. Par ailleurs, bien qu'initiative de Microsoft, AMD annonce que C++ AMP sera disponible également sous Linux et que ce support sera mis en place autant pour ses APU que pour ses GPU.

Depuis quelques temps, AMD travaille avec Oracle pour intégrer le support de la HSA dans Java 9 Sumatra et rendre l'utilisation des cores massivement parallèles aussi simple que possible. Un projet ambitieux et en attendant que cela soit finalisé et disponible, APARAPI initialement limitée à OpenCL dans Java 7 va supporter la HSA dans Java 8 (Project Lambda). Oracle a d'ailleurs réalisé une première démonstration sur base d'une simulation de type N-Body, qui, vous vous en doutez, était nettement plus rapide une fois accélérée par un GPU.

Antec vient d'annoncer l'arrivée de deux nouveaux kits de watercooling tout-en-un, les Kühler 650 et 1250. Contrairement aux modèles 620 et 920 du constructeur qui utilisaient une base Asetek, on retrouve ici un design pour le moins particulier.

La pompe n'est en effet plus placée dans le waterblock, mais au niveau du réservoir, et plus précisément par-dessus le ventilateur (qui semble pour le coup inchangeable, le moteur étant a priori commun). Il s'agit d'un PWM 120mm avec une vitesse de rotation pouvant varier de 600 à 2400 tpm. On ne sait pas si ce design est toujours fabriqué par Asetek, mais de façon custom pour Antec ou s'il s'agit d'un design concurrent qui aurait choisi de s'écarter des designs brevetés d'Asetek (voir ici). La base du waterblock est en cuivre et l'on notera la présence de trois leds sur son dessus pour donner une indication du niveau de température (bleu/vert/rouge).


Le modèle 1250 est encore plus original puisque l'on retrouve, en plus d'un radiateur 240m et deux ventilateurs, deux pompes. Sur ce modèle uniquement, Antec propose un logiciel de monitoring de température et de contrôle PWM baptisé Antec Grid.

MAJ : Antec nous a communiqué le prix de ses kits. Il faudra compter 69.95 euros pour le modèle Kühler 650, et 119.95 euros pour le 1250.

AMD vient d'annoncer un nouveau bundle pour les Radeon R9. Comme c'est le cas pour les R9 290X, les R9 290, R9 280X, R9 270X et R9 270 pourront désormais être livrées avec Battlefield 4. Attention toutefois, le coupon permettant de télécharger le jeu sera inclus directement dans les boites et les références pour cette offre sont donc spécifiques. Les versions BF4 des boites devraient être environ 10 € plus onéreuses que les versions classiques en magasin.

Concernant la R7 260X, AMD annonce par ailleurs qu'elle est désormais éligible au bundle, électronique cette fois, Never Settle Forever dans sa version Silver. Celui-ci permet pour rappel de choisir deux jeux parmi une liste pré-définie . Les bundle NSF s'enrichissent au passage de Thief, dont la sortie est prévue pour février 2014.

Comme prévu, AMD profite de son Developer Summit pour divulguer quelques détails sur son API graphique Mantle. Nous sommes encore loin d'une documentation complète, mais AMD fait en sorte que les développeurs puissent se faire une idée plus précise des possibilités qu'offrira Mantle.

Mantle est une API ou un langage de programmation et de contrôle du GPU qui a été conçu de manière à se débarrasser des obstacles qui compliquent la vie des développeurs de jeux vidéo et plus précisément de moteurs graphiques. A la base de l'initiative d'AMD se trouve une demande très spécifique de Johan Andersson, le développeur principal du Frosbite Engine, demande qui a trouvé écho auprès de la direction d'AMD qui a décidé de tenter de lui donner vie.

Grossièrement, Mantle est une API de plus bas niveau qu'un DirectX ou même qu'un OpenGL. Cela ne veut pas pour autant dire que Mantle revient à programmer le GPU dans une sorte de langage assembleur barbare. Le but d'AMD n'est pas d'arriver au plus bas niveau possible mais d'essayer de placer son API au niveau d'abstraction qui a le plus de sens du point de vue des développeurs de moteurs graphiques. Par rapport à DirectX, une partie de Mantle sera de plus bas niveau, une autre se situera à un niveau similaire et il est même possible que le niveau d'abstraction soit au final plus élevé sur certains points.

N'aurait-il pas été préférable d'essayer de faire évoluer DirectX et OpenGL ? Selon AMD, en plus de prendre une éternité, notamment pour mettre tout le monde d'accord, cela ne permettrait pas d'apporter des solutions à tous les problèmes actuels. Car en fait, plus que de problèmes, il s'agit de compromis. Plus qu'une solution, Mantle est ainsi un compromis différent.



L'un des problèmes principaux des API PC classiques est le surcoût qu'elles engendrent au niveau des commandes de rendu (draw calls), que ce soit lors des différentes vérifications de conformité, lors de leur traduction vers les commandes natives du GPU etc.

AMD indique ainsi que la plupart des jeux se doivent se contenter aujourd'hui de 3 000 à 5 000 commandes de rendu, un chiffre qui peut monter à 10 000 pour les développeurs qui font en sorte d'optimiser au maximum leur rendu. Avec Mantle AMD compte faire exploser les possibilités à ce niveau et permettre aux développeurs d'aisément décupler les capacités de leurs moteurs pour des scènes plus riches en objets et animations.




Tout en visant un niveau de performances optimal et l'ajout de fonctionnalités, AMD a fait en sorte de conserver une API simple, qui permet aux développeurs de visualiser aisément son fonctionnement et d'en prédire le comportement. Cela ne veut pas dire qu'exploiter Mantle sera facile mais que pour un développeur spécialiste de la 3D il n'y aura pas de mauvaise surprise cachée derrière différents niveaux de complexité, de choses étranges qui se passent dans l'API sans qu'il soit possible de comprendre pourquoi.

AMD résume les problèmes sur PC de la sorte : surcoût des API, absence de threading efficace, contrôle de la mémoire limité et absence de contrôle direct du GPU. Pour y répondre, Mantle propose plus de possibilités de précalcul et de réutilisation de certaines données, un contrôle de la gestion de la mémoire et un contrôle de la génération des commandes de rendu ainsi que de leur exécution. L'application contrôle alors directement le rendu et ne transfère plus une partie de cette responsabilité à une "grosse" API.

Une autre façon de voir les choses est de se dire que Mantle transfère aux développeurs des moteurs de jeux vidéo certaines possibilités d'optimisations actuellement exploitées par les développeurs des pilotes d'AMD, si ce n'est qu'ils pourront le faire avec bien plus d'efficacité.



Le fonctionnement basique de Mantle est relativement simple : l'application génère des listes de commandes de rendu qui prennent place dans la file d'attente appropriée du GPU qui les exécute au fur et à mesure qu'il termine les tâches précédentes. La différence fondamentale c'est que ce n'est plus le driver qui gère et réparti les commandes de rendu avec plus ou moins d'efficacité, c'est l'application qui gère le tout aussi finement que le développeur le veut.

Par ailleurs, effacer le surcoût des commandes de rendu n'est pas suffisant, il devient également primordial de proposer un multi-threading efficace, ce que ne permet pas de faire DirectX selon AMD, les fonctionnalités de DirectX 11 à ce niveau s'étant avérées difficiles à exploiter en pratique. Mantle permet à l'application de préparer différentes listes de commandes et de contrôler le multi-threading sans devoir sacrifier les performances ou la robustesse.

L'application acquiert également la possibilité de prendre le contrôle du multi-GPU et de pouvoir décider où exécuter chaque commande rendu. Pour cela AMD a prévu dans Mantle l'accès au moteur de composition CrossFire, au transfert de données entre GPU etc. De quoi autoriser des modes multi-GPU qui iront au-delà de l'AFR et qui s'adapteront mieux par exemple à l'utilisation du GPU computing dans les jeux ou aux systèmes multi-GPU asymétriques comme c'est le cas pour les APU combinés à un GPU. Il est par exemple possible d'imaginer le GPU se charger de la base du rendu et l'APU s'occuper du post processing.



Mantle introduit un nouveau type d'objet : le pipeline monolithique. Grossièrement ce type d'objet permet de définir dans un seul bloc l'empreinte ou la configuration du rendu, ce qui inclut tous les shaders, tous les états GPU etc. Ce pipeline configurable et flexible devrait à termes autoriser de nouveaux types de rendu, impossibles à l'heure actuelle.

Dans l'immédiat, l'intérêt de la chose concerne les performances. Dans DirectX, la gestion des états GPU, des différents shaders etc., peut représenter une charge CPU très lourde. Mantle réduit cette charge et facilite le travail du compilateur qui profite d'une vision globale du rendu.

AMD remet également à plat la gestion de toutes les ressources. Là où DirectX jongle avec de nombreux formats de buffers qui ont chacun leurs limitations liées à leurs usages spécifiques, dont certains sont présents uniquement pour garantir la compatibilité avec d'anciens GPU, Mantle se contente de zones mémoire (Memory) et de zones de rendu (Images). AMD revoit également la manière dont sont attachées certaines données liées au rendu, par exemple les buffers de constantes pour proposer un meilleur compromis entre fiabilité, complexité et performances.



Dans les applications actuelles, les différents buffers se voient attribuer une zone mémoire par le driver d'une façon très rigide, ce qui rend difficile la réutilisation de certaines zones mémoire, multiplie le nombre de ces zones à gérer et amplifie la consommation mémoire totale. C'est en partie pour cela que la consommation mémoire du rendu 3D sur PC est général nettement plus élevée que sur console où les développeurs ont la possibilité de tirer le maximum des ressources disponibles.

Mantle permet à l'application de contrôler directement les transferts de données et la gestion de la mémoire vidéo, pour éviter les automatismes actuels peu efficaces, en partie pour des raisons de fiabilité. Puisque l'application sait précisément ce qu'elle veut faire, de nombreuses vérifications génériques n'ont plus lieu d'être. AMD précise par ailleurs qu'une partie de ces vérifications automatiques est redondante sur PC, les moteurs s'en chargeant directement dans certains cas puisque cela peut déjà être nécessaire sur console.

Mantle permet également aux développeurs de facilement réutiliser le résultat de certaines opérations, sans devoir les répéter parce qu'en stocker le résultat était trop complexe ou ne correspondait pas aux critères stricts de DirectX.

Mantle repose bien entendu sur la gestion par les GPU récent d'une mémoire virtuelle unifiée et AMD précise que cela ne limite pas son support aux récents GPU Hawaii et Bonaire, qui sont les premiers à proposer un support complet à ce niveau. Sans rentrer dans le détail, AMD indique que le support des premiers GPU GCN est suffisant pour permettre de faire tout ce qui est nécessaire pour Mantle.



AMD cite quelques premiers exemples d'utilité de Mantle. Par exemple, préparer certaines données est coûteux (vider le cache, les décompresser…) alors qu'il peut s'avérer qu'elles ne sont pas toutes nécessaires, ce que ne peuvent pas savoir le pilote et une API classique, mais ce que peut contrôler l'application.

Mantle permet de profiter plus souvent d'un cache des shaders et d'éviter un maximum de phases de compilations, coûteuses soit en performances soit en temps de chargement. Il est également possible de rendre conditionnelles certaines phases de rendu et donc de profiter d'un pipeline dynamique. Par exemple lorsque la tessellation est activée, si un objet n'a pas besoin de tessellation, DirectX va devoir traiter la tessellation avec un niveau d'expansion géométrique nul, ce qui a un coût qui peut être non négligeable, alors que toutes les phases du rendu liées à la tessellation pourraient être totalement évitées avec Mantle.

AMD pourra exposer toutes les capacités de ses GPU au niveau de l'antialiasing de type multisample, de quoi laisser les développeurs profiter, s'ils le veulent, de modes actuellement accessibles uniquement aux pilotes.


Au final, Mantle va permettre selon AMD d'aider les systèmes d'entrée de gamme, de permettre aux développeurs de mieux prédire les performances et le comportement de leurs moteurs ainsi que de partager les optimisations entre PC et consoles next gen, et à plus long terme de permettre l'arrivée de nouvelles techniques de rendu.

Pour cela, AMD a cependant besoin d'outils efficaces et indique que le tout est en bonne voie. Par ailleurs, AMD a intégré une large partie de ses fonctions de débogage et de validation directement dans l'API, ce qui facilite la création d'outils efficaces et plus précis sur les bottlenecks éventuels. Les développeurs pourront également intégrer directement l'accès aux différents compteurs du GPU dans leurs propres outils, d'une manière plus complète qu'actuellement.

AMD indique que de son côté le développement avance bien et que le timing de décembre pour le patch Mantle de Battlefield 4 reste d'actualité. Actuellement, Mantle est proposé en version alpha à une poignée de développeurs, mais d'ici quelques temps une version beta sera proposée à de plus en plus de développeurs, s'ils en font la demande. Pour une documentation publique, il faudra probablement attendre la GDC de mars 2014 alors que la disponibilité de la version finale de Mantle est prévue pour la seconde moitié de l'an prochain. D'ici là, le support de l'API sera bien entendu intégré dans tous les pilotes.

AMD insiste sur le fait que Mantle n'a pas été prévue pour être limitée à une architecture. La base de Mantle se contente de fonctions relativement génériques qui pourraient être supportées par d'autres architectures alors qu'un niveau étendu de Mantle apporte le support de fonctionnalités actuellement spécifiques aux Radeon. Mantle pourrait ainsi potentiellement devenir un standard avec des extensions, mais rien ne dit que cela intéressera Nvidia ni que la direction d'AMD n'y posera pas des conditions difficiles à accepter.

Notez que, le forum d'AMD n'étant fermé à personne, à la sortie de cette présentation liée à Mantle, nous avons pu croiser plusieurs employés de Nvidia, dont un des architectes principaux des GPU GeForce. Le concurrent d'AMD semble visiblement aussi curieux que nous au sujet de Mantle !