Depuis la sortie de Vulkan 1.0 en février 2016, le successeur d'OpenGL a lentement mais sûrement fait son chemin dans les applications et les moteurs de jeux. Aujourd'hui, environ deux ans plus tard, le groupe Khronos publie les spécifications Vulkan 1.1 et SPIR-V 1.3, et tout comme le lancement d'API `` dur '' de Vulkan 1.0, celles-ci sont accompagnées d'outils de développement mis à jour, de tests de conformité open source et de prise en charge des pilotes de lancement. des fournisseurs de GPU.
Bien que l'adoption n'ait pas été aussi rapide que certains utilisateurs l'auraient souhaité, les fonctionnalités et les fonctionnalités de Vulkan 1.0 n'ont jamais été le problème. Contrairement au DX12 pris en charge par Microsoft et au Metal pris en charge par Apple, le consortium industriel du groupe Khronos est composé de sociétés membres qui ratifient les spécifications et n'offrent pas le même type de ressources de développement unifié, d'outils et de didacticiels.
Dans cet esprit, où la version 1.0 mettait principalement l'accent sur le logiciel et les spécifications eux-mêmes, la version Vulkan 1.1 est associée au développement ultérieur de l'écosystème Vulkan, Khronos annonçant un nouveau «Vulkan Ecosystem Forum» public pour faciliter les commentaires et la collaboration des développeurs. Et cela rejoint également les efforts de Khronos pour étendre le support de la plate-forme, où la semaine dernière une collection open-source d'outils et de bibliothèques a été publiée pour porter les applications Vulkan vers macOS et iOS, dans le cadre de l'Initiative de portabilité Vulkan.
En résumé, l'évolution de Vulkan de 1.0 à 1.1 comporte trois volets: intégration des fonctionnalités demandées par les développeurs, prise en charge des pilotes et portage transparent de Vulkan vers plus de plates-formes, puis mise en œuvre pratique via un écosystème développé.
Points forts de Vulkan 1.1 Spec
Passant directement aux changements fondamentaux, Vulkan 1.1 apporte deux nouvelles fonctionnalités étendues: le contenu protégé et les opérations de sous-groupes. Le premier utilise des restrictions de bas niveau de sorte que les applications peuvent effectuer le rendu et l'affichage en utilisant des ressources auxquelles elles ne peuvent pas accéder ou copier, garantissant ainsi la lecture et l'affichage du contenu protégé. Bien que soi-disant à des fins de DRM, Khronos a noté que Vulkan exposait la capacité du GPU plutôt que de pousser pour un DRM au niveau du matériel, laissant l'utilisation ou la mise en œuvre aux développeurs.
Ainsi, d'une part, les développeurs peuvent choisir de créer un schéma DRM multicouche hautement restrictif avec un degré élevé de granularité. D'un autre côté, la fonctionnalité pourrait peut-être être utilisée pour un bloqueur de publicités avancé de bas niveau, non seulement pour les navigateurs, mais aussi pour des applications et des jeux et applications mobiles et de bureau. Tout pourrait être possible avec Vulkan 1.1 et au-delà. À cette fin, Vulkan cherche à bien des égards simplement à activer ce qui est possible - au sens le plus pur de l'idée - sur les GPU.
Cette idée se poursuit avec les nouvelles «opérations de sous-groupe», où un ensemble de threads peuvent communiquer et se coordonner entre eux là où normalement cela serait fait en accédant à la mémoire hors puce. En fin de compte, cela offre aux développeurs une méthode de parallélisation de certaines charges de travail à un très haut degré, et bien que le calcul et l'apprentissage en profondeur soient les cas d'utilisation les plus évidents, les opérations de sous-groupes ne se limitent pas à calculer des shaders et pourraient vraisemblablement être utilisées à des fins graphiques. Naturellement, le nouveau SPIR-V 1.3 prend également en charge les opérations de sous-groupes. (ed: tout cela semble très Volta-ish, même si je m'attends à ce que les futurs GPU implémentent également la technologie sous-jacente)
Les autres intégrations de base 1.1 proviennent d'extensions préexistantes, qui sont maintenant promues au niveau d'extensions le plus intégré de l'API. Beaucoup de ces extensions sont axées sur la réalité virtuelle ou sur une certaine polyvalence améliorée, y compris le rendu simultané sur plusieurs vues d'images (par exemple accélération multi-projection), interopérabilité inter-API et inter-applications / processus, prise en charge de YCbCr et groupes de périphériques pour des configurations homogènes multi-GPU.
Façonner un `` écosystème Vulkan '': plus de soutien, de meilleurs outils
Pour toutes les spécifications et fonctionnalités, Vulkan est toujours une API, alimentant d'autres applications, moteurs et jeux. Au cours des deux années qui ont suivi la sortie de Vulkan 1.0, une variété de nouveaux jeux de bureau mobiles et multiplateformes alimentés par Vulkan ont continué à se répandre; tout en reconnaissant les problèmes potentiels liés à la citation de Wikipedia, Khronos souligne qu'il existe des quantités comparables de jeux compatibles DX12 et Vulkan plutôt qu'une majorité DX12 significative. À notre avis, il y a certainement plus d'AAA Windows jeux où DX12 est l'API préférée, mais grâce en partie au taux d'adoption lent des deux côtés, ce n'est pas aussi déséquilibré que Direct3D contre OpenGL.
Mais en tant que solution propriétaire prise en charge de manière monolithique par Microsoft, DX12 dispose d'un large éventail de ressources centralisées et préexistantes. De plus, DX12 peut être directement poussé via Microsoft Studios et UWP. Pendant ce temps, Khronos est un consortium industriel et ne possède naturellement pas de capacité de développement interne ou n'offre pas ce type de soutien direct aux développeurs.
En doublant l'approche open-source, Khronos recrée également un écosystème ouvert avec le nouveau «Vulkan Ecosystem Forum». Étant en communication avec les développeurs d'autres plates-formes ainsi qu'avec les concepteurs d'API et les groupes de travail de Vulkan lui-même, le forum apporterait idéalement un degré de centralisation et une source de progrès actif pour les développeurs sans imposer de mandat spécifique, un peu comme la spécification Vulkan elle-même. Au fur et à mesure que de plus en plus de plates-formes sont intégrées, via le Vulkan Portability Initative ou autre, le Forum peut servir de source centralisée de pollinisation croisée pour les développeurs multi-plates-formes. Le Forum fournirait également aux projets open source des orientations durables, ce qui serait particulièrement utile pour les petits projets qui pourraient devenir très utiles.
Cette approche exige également davantage de guides, de ressources et d'outils car ils ne seraient pas examinés, conditionnés et pris en charge de manière monolithique. En ce sens, Khronos et LunarG annoncent plusieurs nouveaux outils de développement Vulkan, dont un Device Simulation Layer. Et avec plus de deux ans d'expérience avec Vulkan 1.0 et ses particularités, Khronos et LunarG ont suffisamment affiné leurs meilleures pratiques pour créer un assistant Layer pour guider les développeurs plus récents et plus anciens dans des situations non directement couvertes ou interdites par la spécification Vulkan.
L'autre point que Khronos a réitéré concernait la concurrence entre Vulkan et DX12. Plutôt que de s'affronter, Khronos a vu que chaque API avait des cas d'utilisation et des forces différents avec un certain chevauchement. Pour les développeurs UWP uniquement, il y a peu de raisons d'envisager Vulkan, tandis que les développeurs qui cherchent à déployer sur plusieurs plates-formes peuvent ne pas vouloir se limiter avec DX12. Avec l'initiative de portabilité Vulkan et gfx-rs en particulier, Khronos vise à implémenter Vulkan sur D3D12, Metal et OpenGL.
Alors que certains ont perçu ces sous-ensembles Vulkan Portable comme un autre exemple d'une norme universelle qui ne devient qu'une autre norme concurrente, Khronos a explicitement mentionné éviter cette approche. En raison des points communs entre Metal, DX12 et Vulkan, ainsi que de la modularité de Vulkan avec des couches et de la polyvalence multiplateforme inhérente à plusieurs fournisseurs, Metal et DX12 peuvent être traités comme des sous-ensembles de Vulkan. De cette manière, Khronos peut simplifier l'équation en permettant aux développeurs de s'appuyer sur Vulkan et de le porter facilement ailleurs.
De cette manière, Khronos s'attaque à ce qu'il considère comme son plus grand obstacle, l'écosystème Vulkan. À l'avenir, Khronos a esquissé une cadence générale de 1 à 2 ans pour le noyau Vulkan et les mises à jour SPIR-V correspondantes, avec des extensions testées, intégrées et déboguées tout au long du processus.
En ce qui concerne les pilotes de lancement, Khronos a noté que AMD, Arm, Imagination, Intel, NVIDIAet Qualcomm avaient tous des pilotes Vulkan 1.1 conformes. Les liens seront mis à jour dès qu'ils seront disponibles.
Le Forum Écosystème se trouve sur son page GitHub spécifique, tandis que la mise à jour SDK LunarG et couches d'outils sont également disponibles. Tous les projets open source de Khronos peuvent être trouvés via le GitHub général.