Un bref aperçu de l'API Vulkan

Alors, quel est le problème avec cette nouvelle API Vulkan de toute façon, et pourquoi devrions-nous nous en soucier ?

Voici l'API Vulkan en une centaine de mots ou moins : il s'agit d'une API proche du métal et à faible surcharge pour les graphiques 3D et les applications de calcul. Vulkan est essentiellement une suite à OpenGL. Il était à l'origine appelé «l'initiative OpenGL de nouvelle génération» et comprend quelques éléments de l'API Mantle d'AMD. Vulkan est censé offrir de nombreux avantages par rapport aux autres API GPU, permettant une prise en charge multiplateforme supérieure, une meilleure prise en charge des processeurs multithreads, une charge CPU réduite et une pincée d'agnosticisme du système d'exploitation. Cela devrait également faciliter le développement des pilotes et permettre la pré-compilation des pilotes, y compris l'utilisation de shaders écrits dans différents langages.

Cela fait 93 mots, donc si vous n'êtes pas intéressé, vous pouvez sauter les 3 500 suivants. Si, par contre, vous voulez en savoir plus sur la prochaine API graphique qui nous accompagnera dans les années à venir, je vais commencer par les bases.

Comment l'API Vulkan est née

Vulkan a été initialement annoncé par le groupe Khronos en mars 2015, avec une date de lancement provisoire fixée à la fin de 2015. Au cas où vous ne seriez pas familier avec Khronos, il s'agit d'un consortium industriel à but non lucratif fondé il y a quinze ans par certains des plus grands noms du monde. l'industrie graphique, y compris ATI (qui fait maintenant partie d'AMD), Nvidia, Intel, Silicon Graphics, Discrete et Sun Microsystems. Même si vous n'avez pas entendu parler de Khronos, vous avez probablement entendu parler de certains de leurs standards, tels que : OpenGL, OpenGL ES, WebGL, OpenCL, SPIR, SYCL, WebCL, OpenVX, EGL, OpenMAX, OpenVG, OpenSL ES, StreamInput, COLLADA et glTF.

A présent, vous pensez probablement "Ah, ce sont ces gars-là", donc je peux sauter le reste de l'intro et me concentrer sur l'API elle-même.

Contrairement à son ou ses prédécesseurs, Vulkan est conçu dès le départ pour fonctionner sur diverses plates-formes, allant des mobiles et des tablettes aux consoles de jeu et aux ordinateurs de bureau haut de gamme. La conception sous-jacente de l'API est en couches, ou devrions-nous dire modulaire, de sorte qu'elle permet la création d'une architecture commune mais extensible pour la validation du code, le débogage et le profilage, sans impact sur les performances. Krhonos affirme que l'approche en couches offrira beaucoup plus de flexibilité, catalysera une forte innovation dans les outils GPU multi-fournisseurs et fournira un contrôle GPU plus direct exigé par les moteurs de jeu sophistiqués.

Maintenant, je comprends que beaucoup de technophiles ont des réserves sur les termes marketing tels que « flexible », « extensible » et « modulaire », mais cette fois-ci, nous avons affaire au vrai McCoy. En fait, c'est l'idée de base derrière Vulkan : il est envisagé comme une API pour les masses, des enfants qui jouent sur des smartphones à leurs parents qui conçoivent des bâtiments et des jeux sur des postes de travail.

En théorie, Vulkan pourrait être utilisé dans du matériel informatique parallèle, pour contrôler des dizaines de milliards de cœurs GPU, dans de minuscules appareils portables et drones jouets, dans des imprimantes 3D, des voitures, des kits VR et à peu près n'importe quoi d'autre avec un GPU compatible à l'intérieur.

Pour plus de détails, je vous propose de jeter un œil à la présentation officielle de Vulkan en PDF.

ADN du manteau AMD

Si l'approche proche du métal semble étrangement familière, vous avez peut-être suivi les annonces GPU d'AMD au cours des deux dernières années environ. AMD a surpris les observateurs de l'industrie lorsqu'il a annoncé son API Mantle en 2013, et il les a surpris une fois de plus lorsqu'il a décidé de débrancher l'API, annonçant en mars 2015 qu'il ne publierait pas Mantle 1.0 en tant que SDK public. En un mot, Mantle a promis d'apporter des améliorations significatives en termes de performances et d'efficacité dans certaines situations, en particulier sur le front du processeur, car cela réduirait les frais de traitement. Cela semblait être une bonne idée, car les joueurs pouvaient assembler des PC personnalisés avec des processeurs un peu plus lents et investir plus d'argent dans des cartes graphiques de premier ordre. Cela semblait également très pratique pour AMD, car la société n'a pas eu de processeur haut de gamme compétitif depuis des années, bien qu'elle ait toujours de bons produits GPU.

Alors que les fans d'AMD en pleurs se rassemblaient pour pleurer le décès de leur sauveur, Mantle a été miraculeusement ressuscité. La bonne nouvelle est venue sous la forme d'un article de blog, rédigé par Raja Koduri, vice-président d'AMD pour l'informatique visuelle et perceptuelle. Par coïncidence, conformément au thème religieux, à une occasion, Koduri a tenu un sermon sur une monture, lors de l'événement de lancement d'AMD à Hawaï en 2013, mais je m'égare.

Blague à part, l'équipe de Koduri a fait du bon travail. Bien que Mantle ne soit pas devenu un nouveau standard de l'industrie, il est devenu une base pour Vulkan. La plus grande différence est que Vulkan ne sera pas limité au matériel AMD GCN ; cela fonctionnera sur beaucoup plus de GPU de différents fournisseurs. Vous pouvez probablement voir où je veux en venir; il est un peu préférable d'avoir une seule API graphique à faible surcharge qui fonctionne sur différents systèmes d'exploitation et plates-formes matérielles que d'avoir des API propriétaires pour différentes architectures GPU, systèmes d'exploitation, etc.

L'API Vulkan prend simplement une bonne partie du gâteau Mantle et le partage avec tout le monde, quel que soit le système d'exploitation, le matériel, la race ou la religion.

Oh, et il y a encore une chose : Mantle a finalement forcé Microsoft et Khronos à faire quelque chose contre le gonflement et l'inefficacité de DirectX et OpenGL. C'était un coup de pied doux et amical dans le postérieur, ou "badonkadonk", comme aime à le dire un camarade Toptaler.

Comment Vulkan se compare-t-il à OpenGL ?

Évidemment, je dois souligner les différences fondamentales entre Vulkan et OpenGL. Khronos a proposé une illustration simple, montrant à quel point la surcharge des pilotes pouvait être éliminée avec la nouvelle API.

Vulkan permet aux applications de se rapprocher du métal, éliminant ainsi le besoin de beaucoup de mémoire et de gestion des erreurs, ainsi que de beaucoup de source de langage d'ombrage. Les pilotes seront plus légers, plus maigres et plus méchants. Vulkan ne s'appuiera que sur le langage intermédiaire SPIR-V, et comme il dispose d'une API unifiée pour les marchés des mobiles, des ordinateurs de bureau et des consoles, il devrait également bénéficier d'un soin plus tendre et affectueux de la part des développeurs.

Mais attendez, cela ne décharge-t-il pas simplement plus de travail sur les développeurs de jeux ? Bien sûr, ils pourront utiliser le matériel plus efficacement, mais qu'en est-il de leurs propres heures de travail ? C'est là que l'approche écosystémique en couches entre en jeu.

Les développeurs pourront choisir trois niveaux ou niveaux différents de l'écosystème Vulkan.

• Utilisez Vulkan directement pour une flexibilité et un contrôle maximum.
• Utilisez les bibliothèques et les couches Vulkan pour accélérer le développement.
• Utilisez Vulkan via des moteurs de jeu prêts à l'emploi entièrement optimisés sur la nouvelle API.

La première option ne conviendra clairement pas à tout le monde, mais je soupçonne que cela ferait un bon logiciel d'analyse comparative. Khronos s'attend à ce que la deuxième option soit un "domaine riche en innovation" car de nombreux utilitaires et couches seront en open source et faciliteront la transition depuis OpenGL. Si un éditeur a des titres OpenGL qui doivent être peaufinés et mis à jour, c'est ce qu'il utilisera.

La dernière option est peut-être la plus tentante car le gros du travail a été fait par des poids lourds de l'industrie tels que Unity, Oxide, Blizzard, Epic, EA, Valve et autres.

Voici un tableau rapide OpenGL vs Vulkan :

Pour être honnête, je ne pense même pas qu'il soit juste de comparer les deux. Vulkan est un dérivé de Mantle, tandis qu'OpenGL est un mastodonte avec 20 ans de bagages. Vulkan est censé abandonner des tas de trucs hérités; exactement. Vulkan est censé rationaliser les tests et la mise en œuvre, alléger les pilotes et améliorer la portabilité du programme de shader via le langage intermédiaire SPIR-V.

Cela nous amène à la question suivante. Que signifie vraiment Vulkan pour les développeurs ?

SPIR-V devrait transformer l'écosystème linguistique

Alors, où SPIR-V entre-t-il en jeu, et qu'arrive-t-il au bon vieux GLSL ?

GSLS restera en vie pour le moment, et ce sera le premier langage d'ombrage pris en charge par Vulkan. Un traducteur GLSL vers SPIR-V fera le gros du travail, et le tour est joué !, vous obtiendrez SPIR-V prêt à alimenter le runtime Vulkan affamé. Les développeurs de jeux pourront utiliser les back-ends SPIR-V et Vulkan, en s'appuyant probablement sur des front-ends de compilateur open source. En plus de GLSL, Vulkan peut prendre en charge les noyaux OpenCL C, tandis que les travaux sur l'ajout de la prise en charge de C++ progressent. Les futurs langages, frameworks et outils spécifiques à un domaine sont une autre option. Khronos évoque même la possibilité de développer de nouveaux langages expérimentaux.

Quoi que les développeurs choisissent de faire, tous les chemins mènent à Vulkan, via SPIR-V, puis à une multitude d'appareils différents.

SPIR-V est censé améliorer la portabilité de trois manières :

• Outils partagés
• Ensemble d'outils unique pour un seul ISV
• Simplicité

Étant donné qu'il n'y aura pas besoin que chaque plate-forme matérielle dispose d'un traducteur de langue de haut niveau, les développeurs en traiteront moins.

Un ISV individuel peut générer SPIR-V à l'aide d'un seul ensemble d'outils, éliminant ainsi les problèmes de portabilité du langage de haut niveau.

SPIR-V est plus simple qu'un langage de haut niveau typique, ce qui facilite la mise en œuvre et le traitement.

Les performances seront améliorées de plusieurs manières, selon la manière dont Vulkan est implémenté :

• Plus de compilateur frontal, une grande partie du traitement peut être effectuée hors ligne
• Les passes d'optimisation peuvent se régler plus rapidement, les optimisations étant exécutées hors ligne
• Plusieurs shaders source se réduisent au même flux d'instructions en langage intermédiaire

Khronos ne précise aucun chiffre de performance et note que "le kilométrage variera certainement". Tout dépendra de la façon dont Vulkan est utilisé. Si vous voulez vérifier les détails granuleux, assurez-vous de consulter le livre blanc SPIR-V.

Vulkan semble prometteur du point de vue des développeurs

J'ai décrit un certain nombre de fonctionnalités qui devraient rendre Vulkan et SPIR-V populaires dans la communauté des développeurs, et Khronos tient également à faire passer ce point. La perspective d'utiliser les mêmes outils et compétences pour développer sur plusieurs plates-formes semble intrigante, surtout maintenant que l'écart de performances entre les différentes plates-formes se réduit.

Bien sûr, développer un jeu AAA à gros budget pour PC restera un processus extrêmement complexe et chronophage, impliquant des tonnes d'argent et de ressources humaines, mais les plates-formes mobiles et les GPU intégrés utilisés dans les derniers processeurs Intel et AMD offrent déjà beaucoup de Performances GPU pour le joueur occasionnel. En outre, les petits développeurs indépendants ou indépendants sont plus susceptibles de travailler sur des jeux occasionnels multiplateformes que sur des titres AAA produits par de grands éditeurs.

Khronos décrit les avantages suivants rendus possibles par SPIR-V :

• Les développeurs peuvent utiliser le même compilateur frontal sur plusieurs plates-formes pour éliminer les problèmes de portabilité entre fournisseurs
• Le temps de compilation du shader/noyau d'exécution sera réduit puisque le pilote n'a qu'à traiter SPIR-V
• Les développeurs n'ont pas à distribuer le code source du shader/noyau, ils bénéficient donc d'un niveau supplémentaire de protection IP
• Les pilotes sont plus simples et plus fiables car il n'est pas nécessaire d'inclure des compilateurs frontaux
• Les développeurs ont une meilleure idée de l'allocation de mémoire et peuvent modifier leur approche d'allocation de mémoire en conséquence

Je suis sûr que vous conviendrez que cela sonne bien, mais il reste encore un long chemin à parcourir.

Vulkan : ça marche, mais c'est un travail en cours

Comme je l'ai dit, Vulkan est encore à peu près un travail en cours, et nous devrions avoir la spécification complète d'ici la fin de l'année. Cependant, d'après ce que nous avons vu jusqu'à présent, la nouvelle API peut débloquer de nombreuses performances, même avec le matériel de la génération actuelle.

La meilleure illustration de Vulkan que j'ai vue jusqu'à présent vient d'Imagination Technologies, l'une des principales équipes de GPU mobiles. Imagination Technologies GPU IP est utilisé dans tous les gadgets iOS, ainsi que dans de nombreuses autres conceptions de système sur puce basées sur ARM, et même dans certaines puces Intel x86 basse tension.

La semaine dernière, Imagination a publié un article de blog détaillant les gains de performances rendus possibles par Vulkan. Son choix de matériel était quelque peu inhabituel : un Google Nexus Player, basé sur un processeur Intel quadricœur rarement utilisé avec le GPU PowerVR G6430. L'appareil a été testé avec le dernier pilote d'API Vulkan pour les GPU PowerVR, tandis que l'exécution de référence a été effectuée sur OpenGL ES 3.0. L'écart de performance était tout simplement stupéfiant.

La scène comprend un total de 400 000 objets, avec différents niveaux de détails, allant de 13 000 à 300 sommets. Le plan large montre environ un million de triangles, quelques alpha sur les plantes et une dizaine de textures différentes pour les gnomes et les plantes. Chaque type d'objet utilise un shader différent et les gnomes ne sont pas instanciés, chaque appel de dessin pourrait être un objet entièrement différent, avec des matériaux différents, mais le résultat final serait similaire.

Néanmoins, il y a une grosse mise en garde : ce n'est pas le genre d'amélioration des performances à laquelle vous pouvez vous attendre dans la vraie vie. L'équipe d'Imagination Technologies a utilisé un scénario exagéré pour mettre en évidence la supériorité de Vulkan, pour le pousser à ses limites, et dans ce scénario particulier, la limite est en faveur de Vulkan contre OpenGL ES. Gardez également à l'esprit que ce test est lié au GPU , mais il reste une bonne illustration de l'utilisation supérieure du processeur par Vulkan.

Comment Vulkan réduit-il l'utilisation du processeur ?

Vous vous souvenez de cette table OpenGL vs Vulkan que nous avions plus tôt, ou pour être plus précis, ce bit de rendu en mosaïque ? Probablement pas, alors voici, en un mot: Imagination a utilisé Vulkan pour dessiner par lots des appels dans des tuiles et rendre une tuile à la fois. Selon l'endroit où se trouve la tuile au moment où l'image est rendue, elle peut apparaître ou disparaître, changer son niveau de détail, etc. Dans OpenGL ES, tous les appels de dessin sont dynamiques, ils sont soumis avec chaque image, en fonction de ce qui se trouve dans le champ de vision. Les appels de dessin qui ont déjà été exécutés ne peuvent pas être mis en cache.

Par conséquent, OpenGL ES a besoin de nombreux appels en mode noyau pour modifier l'état du pilote et le valider. Vulkan ne le fait pas car il s'appuie sur des commandes pré-générées (tampons de commandes) pour réduire la surcharge du processeur et éliminer le besoin de valider ou de compiler pendant la boucle de rendu. L'équipe Imagination a décrit la possibilité de réutiliser les tampons de commande comme "utile dans certaines circonstances" et possible d'utiliser "dans une large mesure" dans de nombreux jeux et applications.

Le deuxième changeur de jeu est la génération de tampon parallèle , qui permet à Vulkan d'exploiter la puissance de tous les cœurs de processeur. OpenGL ES a été conçu avant l'avènement des puces mobiles multicœurs, mais au cours des trois dernières années, l'industrie est passée de deux, quatre, à huit et dix cœurs de processeur, avec les SoC de la série A d'Apple et Nvidia Tegra basé à Denver. puces comme seules exceptions notables. J'ai parlé des tendances du SoC mobile dans l'un de mes articles de blog précédents, couvrant le prochain compilateur Optimizing Android, afin que vous puissiez le consulter pour plus d'informations.

Essayons une analogie : si Vulkan était un moteur à combustion interne, il stockerait et réutiliserait une partie de sa puissance, de la même manière qu'un turbocompresseur et un refroidisseur intermédiaire (tampons de commande), et il pourrait en utiliser quatre, six, huit voire dix cylindres sans perte de rendement (génération tampon parallèle). Comparer Vulkan à OpenGL ES ressemble un peu à comparer un nouveau moteur turbo de taille réduite à un ancien moteur monocylindre sur le Triumph Trophy de votre grand-père.

Eh bien, au moins grand-père était un vrai rockeur, pas un mod.

Le résultat final est un environnement beaucoup plus efficace, capable de faire bon usage de tout le matériel disponible, contrairement à OpenGL ES, qui est lié au processeur dans la plupart des scénarios. Cela signifie que Vulkan peut offrir des niveaux de performances similaires tout en maintenant le processeur à des fréquences d'horloge inférieures, réduisant ainsi la consommation d'énergie et la limitation.

Inconvénients potentiels de l'API Vulkan (alerte spoiler : il n'y en a pas beaucoup)

je ne suis pas tatillon; Je pense qu'il est également important d'énumérer les avantages et les inconvénients de l'API Vulkan. Heureusement, il n'y a pas beaucoup d'inconvénients autres que quelques inconvénients mineurs et, potentiellement, un ou deux gros. Si vous pensez que Vulkan est la meilleure chose depuis le pain tranché et que vous avez hâte de l'essayer dans votre prochain projet, vous voudrez peut-être considérer quelques-uns de ces points :

• Ajout de la complexité du code dans certains scénarios
• Délai de mise sur le marché
• Niveau de soutien de l'industrie
• Vulkan peut ne pas être aussi pertinent ou efficace sur certaines plateformes (desktops)
• Convaincre les développeurs d'utiliser Vulkan sur certaines plateformes
• Compatibilité limitée avec le matériel hérité

Si un développeur souhaite implémenter certaines des fonctionnalités intéressantes décrites dans cet article, cela impliquera une bonne quantité de travail. Chacun devra être implémenté dans le code, mais la bonne nouvelle est que les leaders de l'industrie faciliteront le processus avec de nouvelles mises à jour de pilotes.

Le délai de mise sur le marché est une autre préoccupation, tout comme la mise en œuvre de Vulkan dans les applications et les jeux plus anciens. Vulkan est toujours un aperçu technique ; les spécifications et les implémentations initiales sont attendues d'ici la fin de 2015, donc, de manière réaliste, nous ne verrons probablement pas beaucoup d'applications réelles avant la mi-2016.

Le soutien de l'industrie ne devrait pas être un problème; Après tout, c'est une norme Khronos, mais cela peut prendre un certain temps. C'est l'une des raisons pour lesquelles j'ai concentré cet article sur le segment mobile ; Les logiciels et le matériel mobiles évoluent plus rapidement, et il faudra peut-être encore quelques trimestres avant de voir Vulkan avoir un impact sur les plates-formes de bureau. C'est comme ça que l'industrie fonctionne, il y a beaucoup plus de choses à craindre dans le créneau des ordinateurs de bureau : prise en charge des applications professionnelles, hordes de joueurs brandissant une fourche qui se moquent de chaque image déchirée, etc. Cependant, le fait que Vulkan soit dérivé du Mantle d'AMD est encourageant.

Bien que Vulkan puisse faire des merveilles dans un environnement lié au processeur, en particulier avec les SoC mobiles multicœurs, ces gains de performances seront limités sur les plates-formes de bureau. Les ordinateurs de bureau gèrent les processeurs multicœurs avec un niveau d'efficacité supérieur, et la plupart des applications exigeantes sur le plan graphique sont liées au GPU.

Jusqu'à ce que toutes les pièces du puzzle se mettent en place, certains développeurs peuvent être réticents à franchir le pas et à jouer avec Vulkan. Beaucoup de gens n'ont tout simplement pas le temps d'expérimenter et n'acquièrent de nouvelles compétences que lorsque cela est absolument nécessaire. Brûler beaucoup d'argent et gaspiller des heures de travail pour modifier les jeux mobiles existants afin d'utiliser Vulkan à ce stade précoce ne sera pas une option pour de nombreux développeurs et éditeurs.

La compatibilité avec du matériel plus ancien pourrait être une autre source de préoccupation. Vulkan aura besoin de matériel OpenGL ES 3.1 ou OpenGL 4.1, accompagné de nouveaux pilotes. Par exemple, les GPU PowerVR série 6 d'Imagination Technologies peuvent le prendre en charge, mais pas la série 5. La série Adreno 400 de Qualcomm prend en charge OpenGL ES 3.1, mais pas la série 300. Les séries Mali T600 et T700 d'ARM prennent en charge OpenGL ES 3.1, mais la prise en charge fait défaut sur les anciennes conceptions de la série T400. Heureusement, au moment où Vulkan deviendra pertinent, la plupart des appareils dotés de GPU non pris en charge seront hors de propos. Il s'agit notamment de l'iPhone 5/5C, de l'iPad de quatrième génération et des appareils Samsung basés sur certaines puces Exynos de la série 5000. Les appareils basés sur Qualcomm peuvent ne pas être aussi chanceux puisque les GPU Adreno de la série 300 sont utilisés sur des conceptions relativement récentes et prolifiques telles que les Snapdragon 410, Snapdragon 600, Snapdragon 800 et 801. Cependant, je soupçonne que la plupart d'entre eux auront disparu avec le temps. Vulkan devient vraiment pertinent.

Vivre longtemps et rendre

Il est encore trop tôt pour dire si Vulkan changera ou non la donne, mais je pense que vous conviendrez qu'il a beaucoup de potentiel. Je pense que ce sera un gros problème, et je base cette hypothèse sur une décennie d'expérience couvrant l'industrie du GPU. Cela prendra du temps, cependant, et je soupçonne que Vulkan fera sentir sa présence sur mobile avant de commencer à changer le paysage du bureau.

À peu près au même moment, les pilotes, les moteurs de jeu et les jeux optimisés pour Vulkan, nous aurons du nouveau matériel avec lequel jouer, et je ne parle pas seulement de modifications matérielles mineures. Le développement de SoC mobiles est au point mort pour un certain nombre de raisons que je n'aborderai pas maintenant, mais 2016 sera une grande année pour l'industrie, car les nœuds FinFET 14/16 nm deviennent disponibles pour davantage de fabricants et deviennent économiquement viables pour le matériel grand public plutôt que puces phares.

Les développeurs disposeront d'un matériel beaucoup plus puissant et efficace avec lequel jouer, et une nouvelle API graphique à faible surcharge sera la cerise sur le gâteau. J'espère sincèrement que les fournisseurs de matériel cesseront d'utiliser la résolution d'affichage comme gadget marketing, car les résolutions inutilement élevées ne font rien pour la qualité visuelle mais gaspillent toujours de l'énergie. Malheureusement, puisque le consommateur moyen ne comprend pas cela et veut voir de plus grands nombres sur la boîte, je soupçonne que cela n'arrivera pas de si tôt. J'ai l'intention d'examiner ce problème étrange dans l'un de mes prochains articles, donc si cela vous ennuie, restez à l'écoute et n'hésitez pas à vous exprimer dans la section des commentaires.