Agrandir
Groupe Khronos
commentaires des lecteurs
93
avec 53 affiches participantes
Partagez cette histoire
Partager sur Facebook
Partager sur Twitter
Partager sur Reddit
Le groupe Khronos a lancé aujourd'hui Vulkan 1.1, la première grande révision de son API GPU multiplateforme indépendante du fournisseur.
La nouvelle révision standardise une poignée de fonctionnalités qui étaient auparavant proposées en tant qu'extensions. La version complète l'API, apportant la parité avec DirectX 12 de Microsoft dans quelques domaines où elle était absente, améliorant la compatibilité avec DirectX 12 et jetant les bases de la prochaine génération de GPU.
Une fonctionnalité en particulier contribue grandement à combler une lacune de Vulkan par rapport à l'API de Microsoft : la prise en charge explicite de plusieurs GPU, qui permet à un programme de répartir son travail sur plusieurs GPU. Contrairement au SLI et au Crossfire d'autrefois, où la tâche de répartir le rendu entre les GPU était en grande partie gérée par le pilote, ce support donne le contrôle au développeur. Avec cet ajout, les développeurs peuvent créer des « groupes de périphériques » qui regroupent plusieurs GPU physiques en un seul périphérique virtuel et choisir la manière dont le travail est réparti sur les différents GPU physiques. Les ressources d'un GPU physique peuvent être utilisées par un autre GPU, différentes commandes peuvent être exécutées sur les différents GPU et un GPU peut afficher des images rendues qui ont été créées par un autre GPU.
Cette fonctionnalité présente un déficit par rapport à DirectX 12, car elle nécessite des configurations GPU homogènes, où chaque GPU doit correspondre (ou au moins être étroitement lié et utiliser le même pilote). DirectX 12 va encore plus loin, permettant des configurations GPU hétérogènes qui mélangent et associent différents GPU de différents fournisseurs. Cette capacité supplémentaire est intéressante car, bien que plusieurs GPU discrets soient encore relativement rares et ne se trouvent généralement que dans les systèmes de jeu les plus chers, il est très courant que les systèmes aient un GPU discret et un GPU intégré.
Publicité
Vulkan 1.1 est également meilleur pour les applications de réalité virtuelle. La réalité virtuelle nécessite le rendu de deux perspectives différentes de la même scène 3D, une pour chaque œil. C'est possible aujourd'hui grâce à la force brute : d'abord, soumettez toutes les commandes pour dessiner l'œil gauche au GPU, puis soumettez toutes les commandes pour l'œil droit. Avec Vulkan 1.1, les développeurs peuvent utiliser la multivue, où un seul ensemble de commandes de rendu produit plusieurs sorties légèrement différentes avec un seul appel.
Une autre caractéristique notable est que Vulkan 1.1 permet l'utilisation des programmes de shader HLSL de Microsoft. Il existe des différences dans la disposition de la mémoire entre OpenGL/Vulkan et Direct3D. Le matériel, qui doit de toute façon gérer les deux API, peut fonctionner avec les deux mises en page, mais les API graphiques avaient auparavant besoin que les choses soient dans leur propre mise en page préférée. Avec Vulkan 1.1, les dispositions de mémoire Direct3D sont gérées de manière native, et les programmes HLSL qui supposent ces dispositions sont également gérés de manière native. Cela permet aux développeurs de déplacer plus facilement le code Direct3D existant vers Vulkan, car ils n'ont plus besoin de réécrire tous leurs programmes de shader.
Pour prendre en charge cela, une nouvelle version de SPIR-V (la représentation intermédiaire indépendante du fournisseur pour les programmes de shader), la version 1.3, est publiée en tandem avec Vulkan 1.1. SPIR-V a également fait l'objet d'expérimentations intéressantes : une collaboration entre Adobe, Google et Codeplay a produit Clspv, un compilateur qui prend les programmes OpenCL et les compile en SPIR-V. Cela signifie que les programmes écrits pour OpenCL - une spécification de calcul parallèle qui couvre les CPU, les GPU et les DSP - peuvent être exécutés sur n'importe quel GPU doté d'un runtime Vulkan, ce qui inclut certaines plates-formes qui n'ont pas de runtime OpenCL.
La nouvelle version de Vulkan prend également en charge de nouveaux formats de couleurs ; en particulier, l'utilisation des codages de couleur YUV/YCbCr. Ces encodages sont couramment utilisés par les codecs vidéo de mouvement. Cet ajout est lié à une autre nouvelle fonctionnalité de Vulkan 1.1 : la prise en charge intégrée du contenu protégé. Pour le meilleur ou pour le pire, les supports numériques physiques et en continu nécessitent souvent que leur contenu soit crypté et protégé contre la copie, ce qui nécessite la coopération du pilote d'affichage. La capacité de contenu protégé de Vulkan permet à ce contenu d'être utilisé dans le cadre d'une scène rendue par GPU, tout en respectant la protection contre la copie et l'affichage sécurisé. Ceci, à son tour, signifie que les systèmes peuvent utiliser Vulkan pour la composition de bureau, par exemple, tout en prenant en charge les médias protégés.
Publicité
La nouvelle spécification améliore également la programmabilité des GPU avec des opérations de sous-groupe qui permettent de partager les données de diverses manières entre les différents threads d'un calcul basé sur GPU et les types de données 16 bits, ainsi que la prise en charge du partage et de la synchronisation entre processus. des objets GPU et de la mémoire.
À l'exception de la prise en charge hétérogène des GPU, Vulkan 1.1 représente en quelque sorte un point de repère. Au début et au milieu des années 2000, l'API DirectX de Microsoft a sans doute remplacé OpenGL, à la fois en termes de facilité d'utilisation pour les développeurs et de meilleure prise en charge des capacités des GPU modernes. OpenGL, en revanche, languissait. Un effort important a été fait pour moderniser l'API OpenGL, mais divers facteurs de l'industrie ont fait que l'effort a déraillé et abandonné. Pendant ce temps, Microsoft était en quelque sorte le moteur derrière les nouvelles fonctionnalités et API de GPU, encourageant les fournisseurs de GPU à innover dans certains domaines pour répondre aux besoins de Windows.
La création du groupe Khronos, le groupe multi-fournisseurs qui gère OpenGL, Vulkan et certaines autres API, a remis les choses sur la bonne voie, et l'itération régulière des spécifications OpenGL 3.x et 4.x a permis l'API OpenGL indépendante des fournisseurs. pour rattraper le retard qu'il avait perdu par rapport à DirectX. De même, bien que Vulkan soit sorti quelque temps après Direct3D 12, il offrait le même type d'accès GPU de bas niveau que l'API de Microsoft. Vulkan 1.1 couvre pratiquement toutes les mêmes bases que Direct3D 12, et dans certains domaines, en particulier dans l'utilisation des GPU en mosaïque qui ne se trouvent pas dans les systèmes de bureau mais qui sont la norme dans les processeurs de smartphones, il dépasse les capacités de l'API propriétaire. .
Cette quasi-parité atteinte, Khronos ne se contente plus de rattraper son retard : il est désormais en mesure de diriger la conception et les capacités des GPU, en préconisant les fonctionnalités qui ont le plus de sens pour (en particulier) les développeurs de jeux, les développeurs Web et les plates-formes mobiles.
