Toutefois, pour pouvoir exploiter tous les avantages de bas niveau offerts par cette API de nouvelle génération, les développeurs ont besoin de mettre la main dans ses entrailles et côtoyer certaines complexités comme la gestion de la mémoire ou la synchronisation. Ces difficultés pouvant être des sources de démotivation chez certains développeurs, AMD a annoncé la sortie sous licence open source de V-EZ 1.1.0, une couche d’abstraction légère construite sur Vulkan afin d’éliminer les complexités de bas niveau inhérentes à son utilisation. Il faut souligner que la sortie de Vulkan fut basée en grande partie sur les travaux entrepris par AMD. Il n’est donc pas étonnant de voir le fabricant américain de semi-conducteurs pousser en avant des outils pour favoriser son adoption.
Pour se faire une idée de l’utilité de V-EZ, AMD explique que les fonctionnalités comme la gestion de la mémoire, les permutations de pipelines, les passes de rendu, les couches de pipelines, les pools de descripteurs, les couches d’images, etc. sont directement gérées par la nouvelle bibliothèque V-EZ. Pour mieux comprendre les modifications apportées par V-EZ, l’on peut se référer aux images comparatives ci-dessous.
API Vulkan
Couche intermédiaire V-EZ
Au niveau par exemple de la gestion de la mémoire, une grande simplification a été apportée. Les applications ne traitent que les descripteurs d’objet tampon et d’image, tout en ayant la possibilité de spécifier des indicateurs de résidence et de sous-allocation. Les détails de bas niveau comme les types de segments de mémoire et leurs propriétés ne sont plus requis par les applications. La gestion des descripteurs d’objets VkMemory ainsi que les tampons et les images qu’ils supportent n’est plus requise. Pour ce qui concerne les descripteurs, les ensembles de descripteurs et les pools ne sont plus explicitement exposés dans V-EZ. Les applications ne sont plus responsables de la gestion des pools de descripteurs, des tailles de pool, des présentations de jeux de descripteurs ou de la compatibilité avec les pipelines liés.
Pour ceux qui ont déjà commencé l’apprentissage de Vulkan, en plus de la gestion de la mémoire, les barrières de pipeline représentent l’un des sujets les plus difficiles à maitriser dans l’API Vulkan. Pour faciliter la tâche aux développeurs, AMD explique qu’en tant que middleware, V-EZ peut prendre des décisions intelligentes sur le moment et l’endroit où des barrières de pipeline sont nécessaires. Avec V-EZ, les applications ne sont plus nécessaires pour gérer la synchronisation des ressources à tous les niveaux ou pour gérer les transitions de disposition d’images. Les barrières de pipeline sont insérées à la demande lorsque des risques de lecture/écriture sont détectés, souligne AMD.
Concernant, les permutations de pipelines, AMD annonce que la gestion des permutations de pipelines dans Vulkan peut être assez lourde pour les applications. V-EZ allégerait ce fardeau en découplant l’état graphique et le format d’entrée vertex à la création du pipeline. Pour se faire, les applications doivent uniquement spécifier l’ensemble des modules de shader pour un pipeline donné. Tous les états graphiques sont maintenant définis de manière ad hoc pendant l’enregistrement du tampon de commande.
Avec cette couche d’abstraction des fonctionnalités de Vulkan, certains pourraient craindre des inconvénients comme une latence ou un surcoût de ressources lors des appels de fonctions natives. AMD précise que V-EZ n’entraîne qu’une légère surcharge par rapport aux appels natifs d’API Vulkan, ce qui signifie que les performances des applications utilisant V-EZ ne devraient pas se trouver affectées. Selon les tests d’AMD, la surcharge générée serait de l’ordre de microsecondes pour des dizaines de milliers d’appels d’API pendant l’enregistrement du tampon de commande.
En outre, AMD rassure que la plupart des objets créés par V-EZ sont des objets Vulkan natifs. Ils peuvent être utilisés de manière native avec Vulkan. Toutes les fonctions API Vulkan natives qui n’existent pas dans V-EZ peuvent être utilisées avec les descripteurs d’objet Vulkan renvoyés par V-EZ. Cela a également pour but de faciliter la compatibilité avec les applications nécessitant des bibliothèques tierces. Cependant, les objets portant le préfixe vez ne peuvent être utilisés qu’avec V-EZ.
V-EZ est disponible en téléchargement pour tout ce qui souhaite l’évaluer ou l’adopter définitivement. La bibliothèque est compatible avec les versions 7, 8.1 et 10 64 bits de Windows ainsi que les versions 64 bits des distributions Linux Fedora et Ubuntu. Son code qui avait été publié en tant que source fermée est maintenant disponible au format open source.
Source : GitHub, GPU Open
Et vous ?
Avez-vous testé V-EZ ;? Quel est votre retour d’expérience ;?
V-EZ pourra-t-il réduire la courbe d’apprentissage de Vulkan comme elle l’envisage ;?
Pensez-vous que cette nouvelle bibliothèque encouragera de nouveaux développeurs à adopter Vulkan ;?
Voir aussi
Khronos publie la spécification de Vulkan 1.1 et de SPIR-V 1.3
Vulkan débarque enfin sur macOS et iOS grâce au runtime MoltenVK de Khronos
AMD publie le framework Vulkan nommé Anvil, il est multiplateforme, open source et sous licence MIT
Intrinsic : un nouveau moteur de jeux vidéo open source basé sur Vulkan
Vulkan : premiers retours sur les bénéfices de la nouvelle bibliothèque, des avantages dans les jeux, mais aussi pour les mobiles