Les derniers contenus liés aux tags AMD et Imagination Technologies

Vulkan 1.0 dispo, avec pilotes et jeu beta!

Publié le 16/02/2016 à 15:38 par Damien Triolet

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 :

 
 

La spécification HSA 1.0 disponible

Publié le 19/03/2015 à 11:51 par Guillaume Louel

La fondation HSA (Heterogenous System Architecture) a annoncé cette semaine la publication de la version 1.0 de sa spécification. Pour rappel, le but de cette technologie est de proposer des solutions pour les problèmes d'hétérogénéité des plateformes de calcul - CPU et GPU – qui diffèrent fondamentalement dans leur fonctionnement et dans leur programmation. HSA tente de résoudre certains de ces problèmes, notamment autour de la manière de collaborer autour d'un espace mémoire unique.

Trois documents ont été publiés, ciblant respectivement le matériel, les développeurs bas niveau (ceux qui réalisent les outils, compilateurs, etc) et les développeurs d'applications (avec notamment un support de C++, Java et Python). Toutes ces spécifications sont téléchargeables librement sur le site de la fondation .

Lancé (et toujours présidé) par AMD, l'effort HSA regroupe désormais d'autres sociétés, particulièrement dans le monde de la mobilité. La fondation compte désormais parmi ses membres ARM, Imagination Technologies (PowerVR), LG, Mediatek, Qualcomm et Samsung.

GDC: AMD, Intel, Nvidia, Qualcomm... à la GDC

Publié le 02/04/2013 à 08:32 par Damien Triolet

Lors de la GDC, dont l'édition 2013 s'est terminée vendredi dernier à San Francisco, les plus importants fournisseurs de technologies graphiques (les GPU Radeon, Mali, PowerVR, HD Graphics, GeForce, Adreno) étaient présents avec notamment pour but de convaincre les développeurs de jeux vidéo d'exploiter toutes les possibilités de leurs produits récents à travers des techniques de rendu toujours plus évoluées que ce soit sur PC ou dans le monde mobile, qui progresse à vive allure.




En plus de diverses présentations, AMD, ARM, Imagination, Intel, Nvidia et Qualcomm étaient présents à travers des stands principalement exploités pour mettre en avant leurs outils maisons : AMD GPU PerfStudio, ARM Mali Graphics Debugger, Imagination PVRTune, Intel Graphics Performance Analyzers, Nvidia Nsight, Qualcomm Adreno Profiler…


Ici en exemple, l'Adreno Profiler de Qualcomm qui permet d'observer assez facilement le comportement des GPU Adreno et d'appliquer des modifications à la volée pour identifier des bugs ou des goulots d'étranglement (bottlenecks). Il est ainsi possible de modifier un shader, de désactiver la synchronisation verticale, de réduire la taille de toutes les textures, etc., et d'observer l'impact en temps réel sur le smartphone ou sur la tablette.

Les outils de tous les acteurs cités proposent des possibilités similaires, chacun ayant des petits avantages ou inconvénients par rapport à la concurrence. Ils sont en général autant adapté au débogage et à l'optimisation de la partie graphique que de la partie "compute" éventuellement exposée pour les GPU.

Lors de plusieurs rencontres avec des développeurs, nous avons voulu savoir quels outils ils préféraient et pourquoi. La réponse de nos interlocuteurs a été unanime : aucun ! Pourquoi ? Tout simplement parce que la multiplication de ces outils devient problématique et que peu importe leurs qualités ou leurs défauts, devoir utiliser un outil spécifique à chaque marque de GPU est tout sauf pratique, d'autant plus quand il faut en supporter bon nombre comme c'est le cas sous Android.


Même avec seulement 3 acteurs, c'est un problème dans le monde PC comme le rappelle Crytek en parlant des opportunités et défis à venir. Il serait ainsi intéressant que Microsoft et Google proposent des outils de développement plus évolués qu'actuellement et dans lesquels les concepteurs de GPU pourraient venir s'interfacer pour proposer autant de détails que dans leurs propres outils mais d'une manière plus ou moins unifiée.

Notez au passage que Crytek en profite pour rappeler à Microsoft qu'il serait peut-être bon de travailler sur la documentation de DirectX !

HSA, calcul hétérogène: Intel et Nvidia isolés?

Publié le 04/10/2012 à 16:39 par Damien Triolet

Début juin, AMD inaugurait la HSA Foundation en partenariat avec ARM, Imagination Technologies, MediaTek et Texas Instruments. Cette fondation 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. Coup sur coup, elle vient d'accueillir de nouveaux membres importants.

ATI, avant d'être englobé par AMD, avait été le premier à nous faire part de l'ambition d'utiliser la puissance de calcul des GPU à d'autres fins que le rendu 3D en temps réel pour lequel ils ont à l'origine été conçus. Probablement par manque de moyens, ces développements ont avancé très lentement et il aura fallu attendre plus d'un an avec la concrétisation de l'initiative similaire de Nvidia pour que le GPU mette enfin un pied dans la porte du monde du calcul haute performance. Disponible dès début 2007, CUDA a ainsi relégué au second plan toute initiative similaire de la part d'ATI/AMD.

Quelques tergiversations au niveau des choix technologiques et des langages de programmation, ainsi que l'intégration d'ATI dans AMD, ont par la suite empêché toute avancée rapide. Il faut dire qu'avec le projet Fusion d'AMD, l'objectif n'était plus simplement d'exploiter le GPU, mais de profiter de la symbiose GPU + CPU. Par ailleurs AMD a fait le choix, probablement par défaut, de se reposer sur des standards ouverts. A l'inverse, Nvidia a opté pour une approche propriétaire qui lui a permis d'être plus agile et surtout beaucoup plus rapide dans ses développements.

Entre le monde x86 largement dominé par Intel, et le calcul sur GPU dominé par Nvidia, AMD s'est retrouvé dans une situation délicate dans laquelle il était devenu difficile de peser sur les choix technologiques des développeurs et donc de les inciter à programmer pour ses solutions hétérogènes.

Pour sortir de cette impasse, AMD avait besoin de rallier d'autres acteurs à sa cause. Proposer un standard d'architecture pour le calcul hétérogène était une solution naturelle à ce problème, d'autant plus qu'il allait devenir essentiel pour de nombreux autres acteurs : les concepteurs de SoC ultra basse consommation. Lorsque l'enveloppe thermique est limitée, comme c'est le cas pour tous les périphériques mobiles, pouvoir exploiter différents types de cœurs destinés au calcul (séquentiel ou massivement parallèle) permet de maximiser les performances dans plus de cas de figure. En d'autres termes, tout l'écosystème ARM était voué à exploiter le calcul hétérogène et allait faire face aux mêmes problèmes qu'AMD lorsqu'il s'agirait de trouver la meilleure approche pour le mettre en place.

Mi-2011, AMD a ainsi proposé la FSA, Fusion System Architecture, comme base de travail, avec en coulisse le support d'ARM. Un an plus tard, après un changement de nom pour HSA, Heterogeneous System Architecture, AMD a remis tous ses travaux initiaux à une fondation dont les membres fondateurs initiaux incluaient également ARM, Imagination Technologies, MediaTek et Texas Instruments. Les statuts de la fondation laissaient cependant la possibilité à d'autres acteurs de devenir des membres fondateurs s'ils se manifestaient dans les 3 mois, à partir du 1er juin 2012.

A quelques jours de l'échéance, Samsung a ainsi rejoint la fondation en tant que sixième membre fondateur, accompagné par Apical, Arteris, MulticoreWare, Sonics, Symbio et Vivante en tant que membres secondaires. Si l'arrivée d'un poids lourd tel que Samsung était une bonne nouvelle pour la HSA, l'absence de Qualcomm était étonnante. Avec des objectifs très importants au niveau des capacités de ses SoC, et l'arrivée à la tête de son département d'ingénierie d'Eric Demers, l'ancien responsable des architectures GPU d'AMD, il ne faisait aucun doute que Qualcomm voudrait rejoindre la HSA… et pas en tant que membre secondaire.

Les négociations ont probablement été plus compliquées et longues que prévues, mais ont fini par aboutir et la HSA Foundation a modifié ses statuts de manière à faire disparaître la date limite pour l'entrée de nouveaux membres fondateurs. Hier, Qualcomm est ainsi devenu le septième membre fondateur.


En s'adjoignant le poids de presque tout l'écosystème ARM, AMD ne pouvait probablement pas trouver de meilleure approche pour le développement d'un standard dédié au calcul hétérogène et la présentation graphique du site de la fondation ne laisse guère de doute concernant le fait que la porte reste ouverte pour un huitième membre principal. S'il faudra encore convaincre certains acteurs importants tels qu'Apple ou Microsoft, les grands absents restent Intel et Nvidia.

Ceux-ci, d'une part par égo vis-à-vis d'AMD et d'autre part pour ne pas faciliter l'arrivée de concurrence sur des marchés très juteux, restent hostiles à l'arrivée d'un tel standard. Intel veut conserver un contrôle total de sa plateforme, proposer ses propres solutions destinées au calcul massivement parallèle et favoriser l'utilisation des cores x86 qui sont en train de gagner beaucoup en efficacité énergétique. De son côté, Nvidia n'entend pas saboter les premiers succès commerciaux de sa division Tesla liée à l'architecture propriétaire CUDA, et prépare sa propre solution hétérogène.

Pour éviter de se retrouver isolés du reste de l'industrie, nul doute cependant qu'Intel et Nvidia vont suivre de très près l'évolution de la HSA ainsi que ses premières spécifications. Annoncées pour fin 2011, elles ont pris du retard mais seraient maintenant entre les mains de l'ensemble des membres de la fondation pour une publication avant la fin de cette année.

AFDS: AMD, ARM, ImgTech, TI : HSA Foundation

Publié le 13/06/2012 à 08:32 par Damien Triolet


L'AMD Fusion Developer Summit, un forum technologique dédié au calcul hétérogène, a actuellement lieu à Seattle. Ce forum peut être vu comme la réplique d'AMD à la GPU Technology Conference de Nvidia qui s'est tenue le mois passé, mais un point important distingue cependant les deux évènements : AMD conçoit autant des cores CPU que des cores GPU. Plus que le calcul massivement parallèle, qui exploite les GPU, c'est ainsi le calcul hétérogène qui est ici à l'honneur.

Exploiter en symbiose des cores CPU et des cores GPU est complexe, notamment parce qu'ils ne partagent pas encore un espace mémoire totalement unifié, même si l'APU Trinity apporte quelques avancées à ce niveau. L'an passé, AMD avait annoncé la Fusion System Architecture, une tentative d'apporter des réponses à cette problématique de manière à pouvoir fournir une plateforme plus simple à exploiter pour un maximum de développeurs. AMD avait alors précisé vouloir en faire un standard ouvert : publier une documentation complète avant la fin 2011 et mettre en place un consortium pour gérer la FSA.

AMD a pris du retard sur la documentation qui n'est toujours pas disponible, mais a entretemps renommé la FSA en Heterogeneous System Architecture de façon à la détacher de sa marque Fusion. Il y a quelques mois, AMD précisé ses plans au sujet du consortium qui se dénommerait HSA Foundation et se verrait transférer tous ses travaux initiaux.

Cette édition de l'AFDS est l'occasion pour AMD de concrétiser la mise en place de la HSA Foundation, qui est effective depuis quelques jours. Il s'agit d'une organisation à but non-lucratif qui sera dorénavant chargée du développement et de la promotion de ce standard ouvert destiné à simplifier le calcul hétérogène qu'il concerne les PC, les smartphones ou les serveurs. Sa tâche sera également de produire des outils de développements efficaces et d'aider à la formation des développeurs.


AMD transfère à cette fondation la totalité de ses travaux initiaux sur la FSA/HSA, à savoir : un compilateur open source, des librairies et les documentations préliminaires qui concernent la programmation, les spécifications hardware ainsi que les spécifications software. AMD fournis par ailleurs une partie des fonds pour la mise en place de la fondation.

La fondation est bien entendu destinée à accueillir un maximum de membres, qui pourront être de plusieurs types : fondateurs (ce qui est encore possible s'ils y sont invités dans les 90 jours), promoteurs, supporters, contributeurs, universitaires et autres associés. Comme c'est généralement de mise pour ce type d'organisation, chaque membre participe à son budget de fonctionnement suivant son rôle, ce qui représente jusqu'à 125.000$ par an pour les membres fondateurs.


Les représentants des cinq membres fondateurs de la HSA Foundation, qui forment son conseil d'administration actuel.

La mise en place de la HSA Foundation n'aurait pas pu se faire sans son élargissement à d'autres grands noms de l'industrie. La présence d'ARM à l'AFDS l'an passé ne laissait aucun doute sur l'intérêt de la société spécialisée dans les modules destinés au SoC, pour laquelle le calcul hétérogène est la seule solution viable sur le plan énergétique, et c'est donc sans surprise qu'ARM fait partie des membres fondateurs de la fondation. D'autres ont rejoint l'initiative et sont tous liés aux SoC d'une manière ou d'une autre : Imagination Technologies, MediaTek et Texas Instruments.

Chacune de ces sociétés disposera d'un membre au conseil d'administration de la fondation (Manju Hedge, Vice-Président des solutions développeurs destinées au calcul hétérogène chez AMD et ex-CEO d'Ageia; Jem Davies Vice-Président responsable de la division Media Processing chez ARM…) qui sera gérée au quotidien par Phil Rogers, Président de la HSA Foundation et AMD Corporate Fellow.

Reste bien entendu que d'autres grands noms sont malheureusement absents du tableau, tels que Nvidia et surtout Intel. Les membres fondateurs ne désespèrent pas à l'idée de les voir rejoindre l'initiative, sans cependant se faire d'illusion à ce sujet. Mais ce sont, avant tout autre chose, les développeurs qu'ils devront s'attacher à convaincre et pour cela, comme le rappelait Adobe présent également à l'AFDS, il faudra leur proposer des outils complets, performants, simples d'utilisation et fiables. Un gros chantier en perspective.

Vous pourrez retrouver toutes les informations disponibles actuellement sur le site de la HSA Foundation  qui vient d'être mis en ligne mais la documentation complète se fait cependant toujours attendre.

Top articles