Raffiner pour l'efficacité et la simplicité de développement

0
22

Alors que la ferveur initiale envers les API graphiques de bas niveau s'est un peu apaisée depuis leur première apparition au milieu de la dernière décennie, le développement des API est toujours bien vivant. En fait, à bien des égards, c'est mieux que jamais – maintenant que ces API sont acceptées et stables, les développeurs des deux côtés de l'allée peuvent sombrer dans les nouvelles options fournies et tracer où aller dans les années à venir. Pendant ce temps, des systèmes d'exploitation comme Windows 7 ont disparu (mais pas oubliés), et une nouvelle génération de consoles se profile à l'horizon. Donc, à bien des égards, les deux prochaines années sont celles où tout ce qui a été mis en œuvre au cours de la dernière décennie va enfin se concrétiser, et la référence pour la programmation graphique se déplace de plus en plus vers ces API de bas niveau.

Bien entendu, le travail pour le faire n'est jamais terminé. Même en ignorant les développements du matériel graphique lui-même, il y a encore beaucoup de choses en cours en termes de programmation. Comment mieux tirer parti des avantages de la programmation de bas niveau, prendre en charge de nouveaux paradigmes de développement, assurer la compatibilité entre plates-formes, etc., sont tous des sujets actifs, en particulier au sein du consortium Khronos. L'institution de toutes les API Open a lancé sa propre API graphique de bas niveau en 2016 avec Vulkan, et depuis lors, continue à itérer sur Vulkan pour l'améliorer. Vulkan 1.1 a vu le jour en 2018, et c'est aujourd'hui le lancement officiel de Vulkan 1.2

Comme la plupart des projets Khronos, Vulkan est basé sur une progression constante de nouvelles idées suggérées, mises en œuvre, testées et finalement intégrées dans la spécification proprement dite. En conséquence, Vulkan n'est jamais «terminé» – il y a toujours une nouvelle extension au coin de la rue – mais les points de synchronisation qui sont des versions majeures représentent une étape très importante dans le processus de développement. C'est ici que les extensions prennent enfin leurs ailes, dans un sens, et sont promues dans la spécification de base, garantissant leur fonctionnalité et leur disponibilité aux programmeurs sur toutes les plates-formes avec le support de Vulkan. Ainsi, pour Vulkan 1.2, la mise à jour d'aujourd'hui prévoit la promotion de 23 extensions publiées au cours des deux dernières années dans la spécification API principale, avec une disponibilité généralisée qui devrait suivre rapidement.

Pour le meilleur ou pour le pire, Vulkan 1.2 est une version axée sur le programmeur. La nouvelle fonctionnalité est importante, comme tout programmeur qui a la (mauvaise) fortune de jouer avec des sémaphores peut vous le dire, mais la version d'aujourd'hui ne concerne pas les nouvelles fonctionnalités matérielles. En fait, Vulkan 1.2 n'impose aucune nouvelle fonctionnalité matérielle, il s'agit donc uniquement d'une mise à niveau d'API sur place qui peut être déployée sur tout matériel prenant en charge Vulkan 1.1. Bien sûr, Khronos y parvient en partie en rendant plusieurs nouveaux appels d'API facultatifs – des choses comme les shaders FP16 – mais il n'y a pas de grande nouvelle fonctionnalité d'ancrage de Vulkan 1.2.

Cela le rend très axé sur l'amélioration de la qualité de vie des programmeurs (et des propriétaires de plates-formes), qui obtiennent tous de meilleures façons de faire les choses plus rapidement – ils n'ont tout simplement pas nécessairement des moyens de faire de nouvelles choses. Pour les foules de joueurs, des ajouts de fonctionnalités de chapiteau tels que le lancer de rayons, l'ombrage à taux variable et les shaders de maillage arriveront finalement, mais Vulkan 1.2 n'est pas ce genre de version.

Des sémaphores et des langages d'ombrage

Comme je l'ai mentionné plus tôt, Vulkan 1.2 est en grande partie une version de qualité de vie pour les programmeurs. La programmation graphique de bas niveau est difficile, et les meilleures pratiques ont continué à évoluer au cours des 4 dernières années pour mieux utiliser Vulkan et les API similaires sans être un programmeur de calibre John Carmack.

Quel est le plus gros ajout de fonctionnalités pour Vulkan 1.2? Sémaphores chronologiques.

En vérité, j'ai réécrit cette section trois fois en essayant d'expliquer à un haut niveau ce que sont les sémaphores et pourquoi ils sont si importants pour Vulkan. Mais les sémaphores sont un sujet distinctement informatique, et sont donc un sujet distinctement programmeur (par opposition à utilisateur) lorsque l'on parle de Vulkan 1.2.

Néanmoins, les sémaphores chronologiques sont un développement majeur pour l'API. En résumé, les sémaphores sont un moyen de contrôler l'accès aux ressources partagées et de synchroniser les données entre les appareils et les files d'attente; un élément de données pour indiquer quand et comment il est sûr d'effectuer des opérations sur les ressources marquées. Vulkan a pris en charge les sémaphores depuis sa sortie (VkSemaphore), mais comme Khronos l'admet facilement, le précédent mécanisme de sémaphore de Vulkan était nul. Les sémaphores binaires ne sont pas très flexibles – et sont à certains égards plus proches du bon vieux mutex – et bien qu'ils fonctionnent certainement, ils peuvent être inefficaces.

La solution est alors un mécanisme de sémaphore plus robuste, et c'est le sémaphore chronologique. Je n'essaierai pas de surpasser le propre billet de blog de Khronos sur la question, mais l'avancement ici offre une valeur beaucoup plus grande pour les sémaphores – 64 bits au lieu de 1 bit – et rend ensuite ces nouveaux sémaphores visibles à partir des hôtes et des appareils. Le résultat final est que la quantité de travail que les programmeurs doivent faire pour synchroniser les opérations parallèles devrait diminuer, et de même le temps d'exécution perdu sur plusieurs niveaux de sémaphores simples sera réduit.

Encore une fois, l'importance de cela n'est pas dans les nouvelles fonctionnalités, mais plutôt dans l'efficacité pour le matériel et le programmeur. L'un des principaux objectifs de Vulkan est de permettre la soumission de travaux multithread – une limitation qui ne pourrait jamais être correctement résolue dans OpenGL – donc les sémaphores améliorés sont un de ces moyens pour rendre cette tâche encore plus facile. Ce n'est pas une fonctionnalité qui sera jamais sur une boîte de jeu ou dans une interview, mais si vous travaillez avec un programmeur graphique, vous entendrez peut-être un peu moins de malédiction en matière de programmation multithread.

Passant à autre chose, Vulkan 1.2 se concentre sur la portabilité croisée, à la fois à l'entrée et à la sortie de Vulkan. Le corps de développement de l'API travaille sur la question de la prise en charge du langage de shader étendu depuis quelques années maintenant, et avec Vulkan 1.2, nous voyons enfin les fruits de leur travail avec le support du langage de shader de haut niveau (HLSL).

HLSL, en tant que mise à jour, est le langage de shader de Microsoft, qui est utilisé pour DirectX. Comme tant de choses entre Khronos et Microsoft, il est juxtaposé au propre langage de shader ouvert de Khronos, GLSL. Pour des raisons évidentes, Khronos favorise GLSL car ils en ont le contrôle, mais le groupe est également pragmatique: la plupart de l'espace PC (et même une bonne partie de l'espace console) est régie par HLSL, et bien que GLSL ne soit pas où que vous alliez, il est dans l'intérêt de tous de maximiser la compatibilité avec HLSL également.

Le résultat net est que pour Vulkan 1.2, Khronos a atteint la prise en charge complète de HLSL, ce qui en fait un langage d'ombrage de «première classe» au sein de Vulkan, jusque-là avec GLSL. Grâce en grande partie à l'open sourcing de leur propre compilateur HLSL (DXC) il y a quelques années, Vulkan 1.2 peut prendre en charge le shader HLSL modèle 6.2 et inférieur, couvrant essentiellement tout le matériel moderne en dehors des fonctionnalités de lancer de rayons. Sous le capot, tout est alimenté par le format de représentation intermédiaire natif de Vulkan, SPIR-V, avec HLSL étant compilé en code SPIR-V pour une utilisation ultérieure.

L'importance de l'ajout du support HLSL est double. Le premier est qu'il permet un portage plus facile ou le développement multiplateforme de jeux entre les plates-formes Microsoft – DirectX 12 et la famille de consoles Xbox – et tout le reste pris en charge par Vulkan. Donc, que cela signifie porter un jeu DX12 sur Vulkan ou écrire vos shaders une fois dans HLSL et pouvoir frapper Vulkan PC et la Xbox en une seule fois, Vulkan peut maintenant gérer cette situation sans avoir à réécrire (ou même à ré-optimiser fortement) un tas de shaders. Et même si la portabilité n'est pas l'objectif souhaité, si un développeur aime juste HLSL pour ses propres raisons, il peut désormais l'utiliser en tant que langage de shader natif et complet dans Vulkan.

Portabilité maximale

En fait, la portabilité dans son ensemble reste l'un des grands objectifs moteurs de Khronos et de la carte Vulkan. Alors que le rêve d'une API vraiment universelle a pris un coup malheureux, en grande partie grâce à Apple qui est entièrement propriétaire de Metal, les gros bailleurs de fonds de Vulkan ont choisi de mettre leur énergie dans divers efforts de portabilité pour combler ces lacunes, du moins là où cela a du sens. . Le résultat net est des projets tels que DXVK, qui est un émulateur DirectX fonctionnant au-dessus de Vulkan et le catalyseur clé de l'outil de compatibilité Proton de Valve. Ou pour utiliser l'exemple d'Apple, la bibliothèque d'exécution MoltenVK, qui permet d'utiliser Vulkan au-dessus de Metal. Dans les deux cas, Vulkan est utilisé pour fournir la portabilité, soit comme une cible commune pour exécuter du code propriétaire, soit comme une API commune pour exécuter du code commun sur une plate-forme propriétaire.

Enfin, dans une note rapide sur la progression de Vulkan en général, Khronos utilise également le lancement de Vulkan 1.2 pour noter où en est Vulkan avec les développeurs d'applications professionnelles. Une relation qui peut parfois être ténue, les applications professionnelles ont été l'une des premières utilisations d'OpenGL, et bien que les jeux attirent davantage l'attention, ils sont sans doute encore parmi les utilisations les plus importantes de l'API. Pour cette raison, les développeurs derrière ces applications allaient toujours être lents à faire la transition d'OpenGL éprouvé à Vulkan, mais le moment est enfin venu.

La conduite de ceci est quelques facteurs différents. Le plus important, peut-être, est Vulkan ajoutant la prise en charge de fonctionnalités OpenGL plus anciennes telles que l'accélération matérielle de la ligne. Ce qui peut sembler trivial à une époque où les GPU poussent des milliards de pixels, mais pour les programmes de CAO hautement raffinés et autres, c'est ce sur quoi ces programmes sont construits. Et bien sûr, cela n'inclut pas les fonctionnalités Vulkan de nouvelle génération telles que le multi-threading, le calcul et les futures fonctionnalités matérielles. OpenGL lui-même est dans une impasse – il est peu probable que de nouvelles fonctionnalités soient développées – de sorte que de nouvelles fonctionnalités matérielles comme le lancer de rayons seront disponibles, Vulkan sera la voie à suivre pour les utilisateurs OpenGL hérités.

Vulkan 1.2: expédition aujourd'hui, conformité aujourd'hui, pilotes aujourd'hui

En conclusion, comme dans les versions précédentes de Vulkan, Khronos a joué les choses de manière très conservatrice en ce qui concerne leur processus de développement et le lancement de la nouvelle spécification. Plutôt que d'annoncer la nouvelle spécification et de laisser les fournisseurs de matériel se rattraper, Khronos a travaillé en tandem avec les développeurs de matériel pour essayer de lancer Vulkan 1.2 dans un état aussi utilisable que possible.

À cette fin, les tests de conformité de Vulkan 1.2 sont déjà effectués et cinq fournisseurs – les trois fournisseurs de PC plus Imagination et Arm – ont tous déjà des implémentations 1.2 qui réussissent les tests de conformité. En fait, NVIDIA (mise à jour: et maintenant AMD également) fera mieux que cela, et les pilotes Vulkan 1.2 seront prêts aujourd'hui en tant que développeur bêta. Ainsi, même s'il faudra encore un certain temps pour que Vulkan 1.2 commence à apparaître dans les logiciels commerciaux (ou au moins prêts pour la production), le consortium et ses membres se mettent en marche.