Les derniers contenus liés au tag OpenGL

GDC: Vulkan, l'API bas niveau de Khronos

Publié le 03/03/2015 à 09:00 par Damien Triolet

Il y a 6 mois, à travers l'initiative Next Generation OpenGL, le groupe Khronos annonçait l'intention de faire évoluer son API phare pour répondre aux récentes API graphiques de plus bas niveau proposées par AMD, Microsoft ou encore Apple. Des travaux qui ont bien avancés et la GDC est l'occasion d'annoncer formellement Vulkan.


OpenGL est une API qui a été régulièrement critiquée pour son évolution trop lente et pour sa complexité trop élevée. Définie par un consortium qui regroupe tous les fabricants de GPU, des fabricants de SoC, des fabricants de périphériques mobiles, des spécialistes du moteur graphique, etc., cette API souffre de la difficulté de mettre tout le monde d'accord sur les directions principales des évolutions, et encore plus sur les points de détails. Toutes ces sociétés n'ont pas les mêmes intérêts, ce qui entraîne une bonne dose de politique et de lobbying, suivis d'un long processus de négociations. Par ailleurs, l'aspect rétrocompatibilité et le long historique de 22 ans ont fini par devenir des boulets que doit trainer OpenGL.

Dans le monde mobile, Khronos a tenté de gagner en agilité à travers une API dédiée et quelque peu simplifiée, OpenGL ES. Cela a plutôt bien fonctionné jusqu'ici, même si les 2 API partagent certaines limitations. Avec l'arrivée des API de plus bas niveau, initiée par AMD et Mantle, suivie par Microsoft et Direct3D 12 ainsi que par Apple et Metal, il y avait une vraie pression sur Khronos pour revoir en profondeur son API graphique. Une opportunité en fait puisqu'une pression suffisante était nécessaire pour parvenir à mettre d'accord, relativement rapidement, tous ses membres.

Pour se donner un maximum de liberté et probablement pour pouvoir contenter les membres qui tirent un avantage compétitif de la complexité actuelle d'OpenGL, ou de son long historique, un compromis s'est rapidement avéré nécessaire. OpenGL Next ne serait pas un OpenGL mais une nouvelle API, bien distincte. De quoi permettre à Khronos d'avancer les mains libres. OpenGL et OpenGL ES vont continuer à évoluer de leur côté, en restant des API de plus hauts niveaux, bien que certains accès de plus bas niveaux y soient déjà disponibles depuis quelques temps, tout du moins pour les développeurs expérimentés qui parviennent à les dénicher sous les différentes couches de complexité.

Parallèlement à ces API "historiques", la nouveauté que Khronos va proposer se nomme Vulkan, son interprétation de l'API graphique de plus bas niveau. A noter que lorsqu'on parle d'une API graphique de bas niveau, il ne s'agit pas d'attaquer les GPU en langage machine barbare. Un certain niveau d'abstraction est conservé, et représente un compromis entre le contrôle donné aux développeurs et la compatibilité avec une large gamme de processeurs graphiques et de plateformes. Du supercalculateur, au smartphone, en passant par le PC, Vulkan pourra trouver sa place.


Comme les autres API de bas niveau, Vulkan offre un accès plus adapté aux GPU modernes, réduit le surcoût CPU des pilotes et permet l'implémentation d'un multi-threading efficace. Une API de plus bas niveau, qui rend le comportement du pilote GPU plus prédictible, facilite également la portabilité d'une plateforme à l'autre tout en conservant de bonnes performances, un point crucial pour tous les développeurs de moteurs de jeux et de middlewares.

Khronos indique d'ailleurs avoir construit à l'intérieur de Vulkan des mécanismes dédiés spécifiquement à faciliter la portabilité, notamment au niveau du débogage. Des outils multiplateformes performants devraient ainsi pouvoir être proposés. Des développements dans ce sens son déjà bien avancés chez Valve, LunarG ou encore Codeplay.

Pour permettre à Vulkan de voir le jour, une autre évolution majeure était indispensable. Avec OpenGL, les programmes (shaders) qui sont exécutés par le GPU sont écrits dans un langage de haut niveau spécifique, GLSL, et compilés à l'exécution par les pilotes en langage machine exécutable par le GPU. Cela a plusieurs inconvénients, il faut intégrer aux pilotes un compilateur complexe, les temps de compilation peuvent être importants, le débogage est plus complexe, le code source des shaders n'est pas protégé…

Pour éviter tout cela, Khronos introduit SPIR-V, un langage intermédiaire entre le code source et le code machine. Il s'agit d'une évolution du SPIR déjà disponible en OpenCL et qui sera d'ailleurs partagée par Vulkan ainsi que par le futur OpenCL 2.1. Les développeurs pourront précompiler leur code GLSL vers SPIR-V, et les meilleurs d'entre eux ainsi que les fournisseurs de moteurs graphiques pourront optimiser directement ce code SPIR-V.


Khronos envisage de faire passer en open source le compilateur GLSL vers SPIR-V pour faciliter l'arrivée d'un riche écosystème, avec par exemple une variante HLSL vers SPIR-V. D'autres langages pourront également être traduits à l'avenir vers SPIR-V et Khronos a prévu que la conversion de et vers LLVM soit possible. Ces outils en sont toujours dans les premières phases de leur développement.

La semaine passée, nous avons pu nous entretenir brièvement avec Neil Trevett, Président de Khronos et Vice Président de l'écosystème mobile chez Nvidia, au sujet de Vulkan. Ce dernier nous a tout d'abord indiqué que de nombreux détails sont toujours en train d'être définis telles que l'implémentation exacte au niveau des pilotes et des OS.

Pour Neil Trevett, qui aborde la question sans détour, l'arrivée de Vulkan ne représente pas une menace dans le monde professionnel pour une société telle que Nvidia qui bénéficie actuellement d'un avantage compétitif énorme à travers son implémentation logicielle robuste d'OpenGL. D'une part Vulkan sera utile pour certaines applications trop limitées par le CPU pour pouvoir profiter des GPU haut de gamme récents de Nvidia et d'autre part l'importance d'OpenGL est loin de s'effacer dans un monde qui a tendance à bouger lentement.

Du côté grand public, tout GPU capable de supporter OpenGL ES 3.1, et donc les Compute Shaders, devrait être capable de faire tourner Vulkan, si bien entendu des pilotes sont développés en ce sens. Du côté PC, tous les GPU qui supportent D3D12 devraient ainsi également supporter Vulkan. Pour les SoC, c'est un petit peu plus compliqué en général, mais du côté de Nvidia, les Tegra K1 et X1 devraient bien entendu en profiter.

Neil Trevett nous a ensuite indiqué, qu'au niveau des OS, Vulkan devrait être rendu disponible partout là où OpenGL et OpenGL ES sont actuellement proposés. En d'autres termes le support devrait être très large et inclura sans problème d'anciennes versions de Windows telles que Windows 7. L'implémentation exacte n'est par contre pas précisée et il restera à voir si les fabricants de GPU développeront bel et bien de tels pilotes.

La possibilité est cependant prévue, et ce n'est pas anodin. Le point fort de Vulkan du côté grand public face aux API concurrentes sera son très large support, des plateformes Windows aux plateformes mobiles, en passant par Steam OS. De quoi redévelopper une présence de Khronos dans le monde du jeu vidéo PC ? Peut-être mais pas tout de suite, les spécifications initiales sont attendues pour cette année et les premières applications ne le sont pas avant 2016.

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

 
 

Le futur Direct3D dévoilé en mars, l'effet Mantle?

Publié le 27/02/2014 à 02:06 par Damien Triolet


C'était un secret de polichinelle depuis quelques temps, Microsoft prépare l'arrivée d'une nouvelle mouture de DirectX et de son API graphique Direct3D. Les premières annonces se feront à la Game Developer Conference (GDC) qui aura lieu du 17 au 21 mars à San Francisco. Comme les années précédentes, nous avons d'ailleurs prévu d'être sur place, d'autant plus en sachant que des choses importantes devraient y être dévoilées autour des API graphiques.

Il ne fait aucun doute que Microsoft va réorienter Direct3D vers une réduction massive du coût CPU des commandes de rendu, AMD ayant ouvert la voie vers cela avec Mantle. Il y a dorénavant une demande importante de la part des développeurs et des possibilités à ce niveau en OpenGL qui pourraient être exploitées par Steam OS. Pour garder le contrôle, Microsoft se devait de réagir.

La plupart des informations à ce sujet sortiront des sessions du jeudi 20 mars :

DirectX: Evolving Microsoft's Graphics Platform (Presented by Microsoft)
DirectX Advancements in the Many-Core Era: Getting the Most out of the PC Platform (Presented by NVIDIA)
Approaching Zero Driver Overhead in OpenGL (Presented by NVIDIA)
DirectX: Direct3D Futures (Presented by Microsoft)

L'intitulé de cette dernière cession est d'ailleurs très clair concernant les orientations du prochain Direct3D :
Come learn how future changes to Direct3D will enable next generation games to run faster than ever before!

In this session we will discuss future improvements in Direct3D that will allow developers an unprecedented level of hardware control and reduced CPU rendering overhead across a broad ecosystem of hardware.

If you use cutting-edge 3D graphics in your games, middleware, or engines and want to efficiently build rich and immersive visuals, you don't want to miss this talk.
Il est intéressant d'observer qu'AMD prendra part à la session sur le surcoût CPU en OpenGL de Nvidia (les équipes de développements de ces deux concurrents arrivent à s'entendre!), alors que c'est avec Oxide Games, qui propose la démo Mantle Star Swarm, que Nvidia s'est associé pour parler de la bonne exploitation des CPU multicores.

Une fois que nous en saurons plus sur ce que ce sera ce futur Direct3D, il restera à voir qui tirera le mieux parti de ce futur Direct3D, l'avantage alternant souvent entre AMD et Nvidia. D'un côté certains pourraient se dire qu'avec Mantle, AMD a irrité Microsoft qui pourrait être tenté de favoriser Nvidia. C'est possible, mais d'un autre côté AMD a également enlevé une épine du pied au père de Windows en lui donnant un prétexte pour une évolution plus radicale face à laquelle certains pouvaient peut-être trainer des pieds. L'expérience de Mantle est par ailleurs une bonne base de travail et de réflexion pour Microsoft, de quoi l'aider à bouger plus rapidement pour ne pas laisser d'avantage au couple OpenGL et Steam OS.

Adobe Creative Suite 6 passe à l'OpenCL

Tags : AMD; H.264; OpenCL; OpenGL;
Publié le 25/04/2012 à 15:11 par Guillaume Louel

Deux billets de blogs d'AMD (ici et ) nous annoncent que la Creative Suite en version 6 d'Adobe, annoncée officiellement lundi, proposera pour la première fois une utilisation d'OpenCL dans certains de ses logiciels, ainsi qu'une utilisation accrue d'OpenGL (déjà utilisable précédemment pour le moteur de rendu de Photoshop par exemple).

Le premier blog cite deux exemples sous Photoshop (parmi un "fantastique nombre" non précisé) d'accélérations. Tout d'abord une nouvelle galerie d'effets de flous dont le calcul est accélérée par OpenCL. Côté performances, AMD indique que l'activation de l'OpenCL sur un APU A8-3530MX (processeur mobile quatre cœurs cadencé à 1.9 GHz) permet de réduire le temps de rendu de 394 à 51 secondes. Le second exemple cité sous Photoshop CS6 concerne l'effet "Liquify" qui profite lui du mode de rendu OpenGL. Sur la même plateforme qu'évoquée précédemment le temps de rendu passe de 86.6 à 15.6 secondes.


Le second blog cite un cas un peu particulier d'accélération OpenCL sous Premiere. Cependant en y regardant de plus près, l'exemple cible spécifiquement la version Mac de Premiere et plus précisément l'export H.264 dont le temps de rendu sur un MacBook Pro 15" passerait de 3 minutes 39 secondes à une minute et 4 secondes en mode OpenCL via la Radeon HD 6750M intégrée à la machine. On rappellera qu'Adobe proposait déjà sous Windows une accélération GPU CUDA de son moteur de rendu Mercury Engine, mais qui ne touchait pas l'encodeur H.264 présent dans le logiciel. Le billet d'AMD laisse penser qu'il s'agit de l'accélération du moteur de rendu, et non de l'encodage lui-même, qui propose l'accélération OpenCL. Il sera bon de voir si cette fonctionnalité sera également portée sur la version PC et si elle fonctionnera sur les autres GPU.

Un point que l'on pourra vérifier d'ici 30 jours, délai de disponibilité effectif annoncé pour CS6, tout comme l'étendu réelle de l'utilisation d'OpenCL. Le modèle de développement itératif de Photoshop et des autres outils Adobe fait qu'assez souvent, les nouveautés technologiques (jeux d'instructions particuliers comme Altivec ou SSE, support du multi-core, etc) ont souvent été implémentées de manière isolée dans certains filtres ou certaines fonctionnalités.

MAJ : Adobe à indiqué sur son forum que le support OpenCL sous Premiere serait bel et bien limité à la plateforme Mac (merci a fir3ball12).

Top articles