ARM vient d'annoncer de nouveaux blocs disponibles pour ses partenaires. Pour rappel, ARM développe en parallèle des architectures (ARMv8-A pour la dernière version 64 bits, le pendant du x86-64 dans le monde du PC) et propose aussi ses propres implémentations de coeurs qui peuvent être utilisés par ses partenaires sous licence (l'équivalent dans le monde PC serait Intel qui autorise ses partenaires à faire des versions "custom" de Skylake).

Certains des partenaires d'ARM disposent d'une licence dite "architecture" (Apple, Qualcomm, Samsung, Nvidia...) qui leur permet de réaliser leurs propres implémentations (de la même manière qu'AMD et Intel proposent des processeurs compatibles, mais différents derrière la même architecture x86-64), même si ces derniers proposent parfois les deux. Qualcomm propose par exemple des puces utilisant les Cortex (implémentation ARM) et ses propres Snapdragon.

La nomenclature des implémentations d'ARM a toujours été compliquée à comprendre, pour ne pas dire autre chose, et autant dire qu'aujourd'hui ARM n'arrange pas son cas avec l'A73. Il fait suite sur le papier au Cortex-A72 qui avait été annoncé en février 2015 même si d'un point de vue technique les puces sont différentes.

Ce diagramme permet d'y voir un tout petit peu plus clair. Après l'époque "simple" de l'A9, ARM a proposé d'un côté des cores de grande taille, visant les hautes performances (A15, A57 et A72), également appelés big. Il s'agit de designs "Out of Order" (le processeur peut changer l'ordre des instructions pour optimiser leur exécution).

En parallèle des coeurs de plus petite tailles ont été présentés (les coeurs LITTLE comme l'A7 et l'A53). Ils utilisent un design dit "In Order" (pas de changement d'ordre) qui simplifie l'implémentation, et réduit donc la consommation de la puce. Leur niveau de performance est plus bas, mais ils disposent d'un meilleur rapport performance/watts que les coeurs big. Leur intérêt théorique est de les mélanger pour créer une architecture asymétrique (big.LITTLE, voir la présentation ici) même si en pratique, ce n'est pas toujours ce qui s'est passé.

Les deux familles sont développées par des équipes différentes (Austin pour les big et Cambridge pour les LITTLE) et au milieu de tout cela, on retrouvait les A12 et A17, mélangés sur ce graph (par une troisième équipe a Sophia-Antipolis). Il s'agissait là aussi de designs "Out of Order" mais un peu plus optimisés pour un meilleur rapport performances/watts.

Si en théorie ces puces étaient présentées comme dédiées au milieu de gamme, en pratique elles proposaient surtout une alternative aux gros coeurs ARM dont la consommation était trop élevée, obligeant de limiter fortement les fréquences pour rester dans l'enveloppe thermique d'un smartphone. On a pu voir un certain nombre de retards lors de la génération A57, particulièrement chez Qualcomm, et une surconsommation importante par rapport à ce qu'espérait ARM. Une situation qui a même poussé certains des partenaires d'ARM a proposer des puces n'utilisant que les coeurs LITTLE, un comble.

Cortex A73 : 10nm

Le Cortex A73 est présenté par ARM comme son nouveau coeur big. Il fait suite à l'A72 (16nm) et sera proposé pour les processus de fabrication 10nm. Mais contrairement à ses prédécesseurs big 64 bits (A57 et A72, c'est dur à suivre !), il s'agit sur le papier du successeur des A12/A17 (qui eux n'étaient disponibles qu'en 32 bits).

Contrairement aux A57/A72 qui pouvaient décoder trois instructions par cycle, on se limite cette fois ci à deux sur l'A73. En contrepartie, le pipeline (le nombre d'étapes par lequel les instructions passent) est significativement réduit, passant de 15 à 11 étapes. C'est au niveau du front end (récupération des instructions, décodage, changement d'ordre) que la réduction se fait. On retiendra deux changements importants, d'abord le fait que les instructions en virgules flottantes/NEON (l'équivalent des instructions vectorielles type SSE dans les architectures x86) soient traitées séparément via un décodeur distinct. La seconde est un changement au niveau des instructions arithmétiques entières avec des unités moins nombreuses mais plus performantes.

Bien que décodant une instruction par cycle en moins, l'A73 permet sur le papier au final de dispatcher 6 micro-instructions par cycle, contre 5 pour l'A72. Si l'on ajoute toutes les autres optimisations (le sous système mémoire, point faible historique des Cortex semble avoir évolué), l'A73 est annoncé comme 10% plus performant que l'A72, à fréquence/process égal.

Dans le détail, ARM annonce plus spécifiquement 15% de gains sur les copies mémoire, et 5% sur un encodage FFMPEG utilisant les instructions vectorielles NEON. Notez qu'a process égal, un coeur A73 est 25% plus petit qu'un coeur A72 et consomme 20% d'énergie en moins. En 10nm, un coeur A73 ne mesure que 0.65mm2.

Pour les puces que l'on retrouvera dans le commerce, ARM annonce 30% de performances en plus par rapport aux A72 en profitant du 10nm et de la baisse de consommation pour augmenter la fréquence. Un autre gain significatif mis en avant par le constructeur est que ses puces ne devraient plus voir leur fréquence chuter drastiquement lorsque l'on utilise tous les coeurs en simultanée.

Sur le papier l'A73 est un meilleur compromis côté architecture que ses prédécesseurs, ce qui devrait ravir les partenaires d'ARM, assez peu heureux des A57. Si ARM vise le 10nm, en pratique il propose à ses partenaires des designs A73 en 28, 16 et 10nm. D'ici la fin de l'année, des SoC 16nm devraient faire leur apparition et c'est probablement là qu'on les trouvera en masse (le 10nm sera probablement, pour rappel, réservé au moins dans un premier temps aux gros acteurs du marché comme Qualcomm et Apple à l'image de ce que l'on avait vu avec le 20nm).

Mali-T71 et Bifrost

L'autre annonce d'ARM concerne les GPU. En plus de blocs CPU, ARM propose également à ses partenaires des blocs graphiques qu'ils peuvent utiliser ou non (d'autres sociétés comme Imagination Technologies proposent par exemple leur PowerVR) pour créer leurs SoC.

La nouvelle puce est baptisée T71 et vient faire suite aux GPU T800 dont nous vous avions parlé l'année dernière. Le changement de nomenclature annonce en réalité un changement d'architecture, on passe de l'architecture Midgard à la bien nommée Bifrost.

La transition est importante avec un changement complet de philosophie, passant d'un modèle VLIW (Very Long Instruction Word) à un modèle scalaire... soit exactement la transition qu'avait effectué AMD avec GCN !

La transition aux unités scalaires change en pratique l'ordre dans lequel les données sont traitées, en simplifiant la compilation des shaders (le parallélisme étant extrait des threads, et non d'assemblage d'instructions par le compilateur).

Les threads - clauses dans le langage ARM - sont particulièrement optimisées avec des caches a tous les niveaux (sous la forme de register file) pour s'assurer que les accès mémoires soient optimisés au mieux. Cumulé à tout les autres changements architecturaux (le tiler a également été modifié pour réduire sa consommation mémoire), ARM annonce 50% de gains de performances avec Bifrost.

En pratique le Mali-T71 est le premier GPU ARM utilisant Bifrost, il regroupera jusqu'à 32 shader cores (qui comptent chacun 12 unités scalaires) et reste compatible comme ses prédécesseurs avec OpenGL ES 3.x, OpenCL 2.0 et Vulkan. On rajoutera un dernier mot sur l'interconnexion puisque l'on a droit à un accès au cache fully coherent, ce qui signifie que CPU et GPU peuvent partager la même mémoire cache en opérant en parallèle sans blocage (à la manière de Kaveri chez AMD qui utilisait cependant deux bus distincts), ce qui pourra être utile pour des tâches compute ou l'on fait travailler de concert CPU et GPU (ce qui n'est pas forcément la majorité des usages sur les plateformes mobiles).

Lors de la GDC, nous vous indiquions qu'Imagination proposait un framework destiné à faciliter l'utilisation de l'API Vulkan. Avec VKCPP et surtout NVK dévoilé à l'occasion de la GPU Technology Conference (GTC), Nvidia suit la même voie.

Comme vous l'aurez sans aucun doute compris, maîtriser les nouvelles API de bas niveau est loin d'être aisé. Si elles ouvrent de nouvelles possibilités et permettent aux meilleurs développeurs de produire un code plus efficace sur le plan des performances, elles sont moins abordables et les opportunités explosent pour les bugs en tout genre. Proposer des outils qui en simplifient la bonne exploitation est donc assez logique pour Nvidia et particulièrement en ce qui concerne Vulkan qui va intéresser les développeurs au-delà du jeu vidéo, domaine qui peut se satisfaire plus facilement d'API complexes mais bien exploitées par une poignée de gros moteurs de jeu. Le potentiel de cette API est en effet très varié du côté professionnel mais encore faut-il convaincre les développeurs de sauter le pas.

Lors de l'annonce du framework d'Imagination, Nvidia nous avait indiqué également proposer un outil similaire avec Vulkan C++, ou VKCPP. Ce n'était en fait pas tout à fait correct, mais Nvidia travaille également sur NVK qui s'en rapproche beaucoup.

VKCPP est un portage de Vulkan, une API de type C, vers C++. Certains aspects du code gagnent en clarté, d'autres peuvent être condensés et le compilateur s'assure de la validité de certaines commandes, là où Vulkan classique va autoriser des opérations qui les pilotes n'acceptent pas. Nvidia précise cependant que VKCPP reste une solution destinée aux experts, qui ne rend pas réellement plus abordable l'API Vulkan.

Une solution différente destinée à s'attaquer à ce problème est cependant en développement, NVK, son nom de code actuel (il pourrait changer).

Le but de NVK est de permettre aux développeurs d'obtenir un premier résultat très rapidement. Pour cela, ce framework va proposer des fonctions simples pour les tâches de routine telles que le suivi des ressources, l'allocation de la mémoire, la préparation du framebuffer etc. NVK empêche également les développeurs de faire par erreur des opérations qui n'ont aucun sens mais qui peuvent entraîner toute une série de bugs plus ou moins difficiles à corriger.

Au final, la démo HelloVulkan de Nvidia, qui consiste simplement à dessiner un triangle, demande 750 lignes de code avec l'API Vulkan classique. En passant par le prototype actuel du framework NVK, 200 lignes de code suffisent. Et même si une bonne partie de ces lignes de code supprimées représentent des aspects triviaux pour la plupart des développeurs, ils sont surtout des sources de bugs potentiels éliminées.

Par ailleurs, ce n'est pas seulement le développement initial qui se trouve simplifié, mais également l'évolution et la maintenance du code. Des aspects cruciaux pour bon nombre de développeurs. Reste cependant à voir si Nvidia compte proposer des back-ends pour des solutions autres que ses propres GPU. Ce ne sera peut-être pas directement le cas, mais VKCPP est un projet open source disponible sur GitHub  et de toute évidence il devrait en être de même pour NVK.

Vous pourrez retrouver la présentation complète de Nvidia ci-dessous :

Maîtriser les API de plus bas niveau telles que Direct3D 12 et Vulkan représente un challenge pour les développeurs, celles-ci ajoutant à leur travail un niveau de complexité supplémentaire. Mais à travers son nouveau framework, Imagination va essayer de leur simplifier la tâche.

A l'occasion de la GDC 2016, Imagination a rendu disponible la version 4.1 de son SDK  et à l'intérieur de celui-ci un nouvel outil a fait son apparition : le PowerVR Framework. Il représente une couche intermédiaire entre un moteur graphique et une API moderne.

Le niveau de complexité des API de plus bas niveau, que ce soit Direct3D 12 ou Vulkan, va amplifier le besoin de middlewares et de moteurs de jeu prêts à l'emploi. Mais il y a malgré tout encore pas mal de développeurs qui préfèrent mettre en place leur propre solution et pourraient profiter d'un accès simplifié aux nouvelles API. C'est en partant de ce constat qu'Imagination a développé le PowerVR Framework.

Le but est simple : aider les développeurs. Pour cela, ce framework est basé sur un ensemble de bibliothèques statiques qui vont permettre de simplifier les tâches courantes telles que la création des objets, les transferts de données, la gestion du multi-threading etc. Il représente une réintroduction d'un certain niveau d'abstraction là où il n'impacte pas la flexibilité et les performances.

A titre d'exemple, Imagination nous explique que sa démonstration Gnome comprenait à l'origine plusieurs milliers de lignes de code qui ont pu être résumées en centaines de lignes en les réécrivant contre ce nouveau framework. De quoi rendre le code plus abordable et plus facile à maintenir, deux arguments qui ne devraient pas laisser les développeurs indifférents.

Ce framework permet également de supporter plus facilement différentes API et différents types de plateformes. Il peut ainsi viser autant OpenGL ES que Vulkan. Par ailleurs, en plus d'un back-end pour les GPU PowerVR, il en propose actuellement deux autres pour les GPU AMD et Nvidia. Suivant les retours des développeurs, Imagination n'est pas contre l'ajout de back-ends supplémentaires pour les GPU Qualcomm et ARM. L'objectif principal étant que les développeurs exploitent cet outil qui permet de tirer plus aisément le meilleur de ses GPU.

Il n'est par contre pas prévu de l'étendre pour supporter Direct3D 12, les GPU PowerVR n'ayant actuellement pas de présence sur la plateforme Windows. Mais compte tenu des difficultés rencontrées par les développeurs, Imagination s'attend à ce que quelqu'un d'autre propose un outil similaire, peut-être directement Microsoft.

Mise à jour de 19h30: Nvidia nous indique avoir sorti discrètement le mois passé un outil qui a des objectifs similaires : l'API open source Vulkan C++ . Il s'agit également d'une couche intermédiaire qui permet de passer l'API Vulkan C classique vers une approche de type C++ plus simple à manipuler.

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

Après 18 mois de gestation, Khronos annonce la disponibilité immédiate de la variante plus bas niveau d'OpenGL : Vulkan. Pour les premiers pas de cette API graphique qui promet une meilleure exploitation des différentes plateformes, sont directement proposés des kits de développements, des pilotes et même le portage beta d'un jeu PC.

Il y a un an, lors de la GDC 2015, Khronos dévoilait Vulkan, sa vision de l'API graphique de plus bas niveau. Face à Mantle, Direct3D 12 ou encore Metal, Khronos se devait de réagir rapidement pour rester dans la course. Avec cette concurrence et une demande insistante des développeurs, une évolution radicale d'OpenGL, son API graphique historique, était aussi nécessaire que difficile à mettre en place. Pour bouger rapidement et éviter tout compromis boiteux, Khronos a pris la décision de mettre au point une API complémentaire à OpenGL et non de faire évoluer cette dernière vers un plus bas niveau d'abstraction. OpenGL et Vulkan vont coexister, évoluer côte à côte dans le futur, partager certains points communs mais rester distinctes sur d'autres.

Ces API de plus bas niveau permettent aux développeurs de mieux contrôler le GPU et sa gestion, ce qui a pour principal effet de réduire le coût CPU des commandes de rendu et d'autoriser une exploitation efficace du multi-threading. En contrepartie, le travail des développeurs se complexifie quelque peu, notamment en ce qui concerne la robustesse de leur code, qui ne sera plus facilitée par de lourdes sécurités mises en place au niveau des API classiques et de leurs pilotes. Ce dernier point est cependant un mal pour un bien puisque les meilleurs développeurs auront tout le contrôle nécessaire pour assurer un code robuste, sans devoir prendre en compte l'inconnue de ce qui peut se passer à l'intérieur des pilotes.

Pour en savoir plus sur la philosophie qui se cache derrière Vulkan, n'hésitez pas à repasser par l'actualité liée à la présentation de Vulkan en mars dernier. Rappelons simplement qu'à la base des travaux de Khronos, nous retrouvons l'API Mantle qui a été "offerte" par AMD (une contribution que Khronos affiche sans détour contrairement à Nvidia qui ne peut s'empêcher d'essayer de la minimiser autant que possible).

Ses fondamentaux sont toujours là, il aurait été inutile de réinventer la roue, mais après 18 mois de travaux, de nombreuses modifications plus ou moins importantes ont été apportées par le groupe de travail mis en place au sein de Vulkan. Dans sa documentation destinée aux développeurs, Nvidia indique ainsi qu'une douzaine de sociétés ont apporté des contributions majeures et au moins le double étaient sérieusement impliquées dans le projet. Neil Trevett, le Président du consortium (et accessoirement le Vice-Président de l'écosystème développeur chez Nvidia) avec lequel nous avons pu nous entretenir, a tenu à insister sur l'implication plus importante que jamais des développeurs de moteurs de jeu.

Si les plus grosses modifications concernent la gestion des ressources et la prise en compte des architectures de type TBDR (Tiled-Based Deferred Rendering), telles que celle des GPU PowerVR, la présence des développeurs a fait en sorte de contrebalancer les demandes spécifiques que pouvaient avoir les concepteurs de GPU pour éviter de trop complexifier l'API.

Vulkan supporte tout type d'extensions, exactement comme OpenGL, mais face à la large plage de possibilités liée au matériel supporté (de type OpenGL ES 3.1 mobile à OpenGL 4.5 desktop et supérieur), Khronos a mis en place des feature sets, soit un niveau de fonctionnalité minimum garanti. Ceux-ci sont définis par plateforme, de préférence par l'organisme qui contrôle la dite plateforme, et par Khronos si cet acteur tiers ne souhaite pas s'impliquer. Ces feature sets sont toujours en cours de finalisation et ne devraient être publiés que d'ici 1 ou 2 mois.

Sur PC, comme vous vous en doutez, Microsoft n'a pas réellement intérêt à pousser l'arrivée de Vulkan, préférant sa propre API Direct3D 12 liée à Windows 10 et qui est également disponible sur Xbox One. C'est donc Khronos qui se chargera de définir le feature set sous Windows (avec un support de Windows XP à Windows 10), après les premiers retours des développeurs et en jonglant avec le lobbying intense d'AMD, d'Intel et de Nvidia. Ce même feature set devrait également être étendu à Linux, même si certaines releases pourraient mettre en place un feature set spécifique. Il sera évidemment possible d'aller plus loin que le feature set, via le système d'extensions.

Sous Android, Google sera aux commandes. Et c'est là le point qui est probablement le plus important pour Vulkan. L'an passé, nous émettions quelques doutes quant au succès de Vulkan. Pourquoi ? Bien que tout cela n'ait jamais été annoncé publiquement, nous savons de multiples sources sûres que Google préparait sa propre API de bas niveau avec pour projet de la rendre disponible sur d'autres plateformes. Mais quelque part entre la GDC et la fin de 2015, Google a changé son fusil d'épaule, est passé au statut de Promoter au sein de Khronos (le plus élevé) et a abandonné son API propriétaire au profit exclusif de Vulkan. Google proposera ainsi un peu plus tard une version d'Android avec intégration complète de Vulkan, ce qui ne manquera pas de faciliter l'adoption de cette API.

Les possibilités pour cette API sont multiples. Vulkan a un intérêt évident dans le monde mobile, en termes de performances directes bien entendu, mais également au niveau des effets indirects que cela peut avoir : un coût CPU moindre implique une réduction de la consommation, un argument de poids. Vulkan devrait également trouver sa place dans le monde professionnel où les moteurs de visualisation sont souvent lourdement limités par le CPU. Vulkan pourra également aider à réduire la latence et à éviter les petites saccades dans le cadre de la réalité virtuelle.

La grosse inconnue se trouve plutôt du côté de nos PC équipés de Windows, ce qui représente l'énorme majorité du jeu PC. Tout le poids de Microsoft étant posé sur Direct3D 12, il y a peu de place pour une autre API de bas niveau. Valve a cependant sponsorisé le développement par LunarG d'un SDK open source et gratuit, disponible dès aujourd'hui pour Windows et Linux, avant une version Android prévue pour un peu plus tard. Et pour démontrer la pertinence de Vulkan sur PC, Khronos met en avant la disponibilité dès aujourd'hui sur Steam d'une version beta de The Talos Principle qui propose un renderer Vulkan . Pour mettre en place rapidement celui-ci, Croteam a travaillé étroitement avec Nvidia.

C'est d'ailleurs une autre observation importante que nous pouvons faire aujourd'hui. Si l'ADN de Mantle d'AMD est bel et bien à la base de Vulkan, ce qui a mis Nvidia dans une position inconfortable au départ, c'est bien ce dernier qui est progressivement devenu le plus actif autour de cette nouvelle API. Nvidia propose ainsi un pilote Vulkan beta à destination de ses GPU Kepler et Maxwell, qu'ils soient GeForce, Quadro ou Tegra, et que ce soit sous Windows 7-8-10, sous Linux ou sous Android 6.0.

Mais surtout, Nvidia est particulièrement actif au niveau de la documentation et des démos fournies aux développeurs et a mis en place plusieurs mécanismes pour aider ces derniers à passer à cette nouvelle API. Le pilote Vulkan de Nvidia accepte ainsi les shaders OpenGL classiques de type GLSL et pas uniquement le langage intermédiaire SPIR-V de la nouvelle API. Par ailleurs, ce pilote autorise de faire tourner Vulkan à l'intérieur d'un contexte OpenGL. De quoi pouvoir faire des essais rapidement et expérimenter avec Vulkan sans devoir repartir de zéro, ce que de nombreux développeurs devraient apprécier.

> Les pilotes Nvidia pour Windows 7/8.1/10 et Linux 

La documentation et les démos de Nvidia pour les développeurs 

Du côté d'AMD, qui en amont a communiqué très peu (ou très mal ?) sur Vulkan, aucun pilote n'a encore été certifié par Khronos  mais nous venons de remarquer qu'un pilote beta est disponible sur son portail GPUOpen. Il est compatible avec tous les GPU GCN, même s'il y a probablement des limitations pour les plus anciens de ces GPU, et supporte Windows 7, 8.1 et 10. La version Linux arrivera un peu plus tard. Nous ne savons pas pourquoi ce pilote n'a pas encore passé la certification de Khronos.

> Les pilotes AMD pour Windows 7/8.1/10 

La documentation d'AMD pour les développeurs 

Du côté d'Intel, un pilote a été certifié par Khronos pour Skylake sous Linux, mais nous ne savons pas quand il sera disponible. Imagination dispose également d'un pilote certifié sous Linux (nous avons pu le voir en démo lors du CES), tout comme Qualcomm sous Android 6.0. ARM est également annoncé comme prêt à fournir un pilote sous peu.

> La page dédiée d'Imagination 

Notons que dans le cas du support sous iOS, qui ne sera pas natif, Apple privilégiant Metal, Vulkan devrait être proposé d'une manière détournée puisque The Brenwill Workshop développe Molten (MetalGL + MetalVK), une surcouche qui permet de faire tourner OpenGL ES ou Vulkan par-dessus Metal. A voir cependant quelles seront les limitations et autres impacts sur les performances.

Enfin, Khronos tient à insister sur le fait que Vulkan, comme les autres API de plus bas niveau, n'est pas fait pour tous les développeurs, compte tenu de sa complexité plus élevée et d'avantages qui ne s'appliquent pas à toutes les situations. Mais au vu de l'intérêt apporté à ces API par les spécialistes du moteur graphique et d'autres middlewares, qui feront le travail pour la plupart des développeurs de jeux vidéo, le premier point ne devrait pas être un obstacle. Attendez-vous à de nombreuses annonces annexes lors de la GDC 2016 qui se tiendra le mois prochain à San Francisco.

Pour plus d'informations techniques, les spécifications de Vulkan sont disponibles sur le site de Khronos  et nous avons ajouté ci-dessous la présentation complète de Khronos destinée à la presse technique :