Alors que les graphiques hautes performances et l’API de calcul Vulkan sont soutenus par de nombreux fournisseurs, Microsoft et Apple sont deux organisations notables qui n’ont pas soutenu cette norme du groupe Khronos. De leur côté, Microsoft préfère évidemment son Direct3D maison. Cependant, Microsoft se prépare à soumettre sa première extension Vulkan.
Dans le cadre des préparatifs pour la soumission de leur première extension Vulkan, du jour au lendemain, il y a eu une fusion vers le Référentiel de spécification Vulkan pour ajouter le préfixe de fournisseur”MSFT”.
Le vk.xml a maintenant une balise MSFT pour représenter toutes les extensions Microsoft Corporation à l’avenir.
Les ingénieurs de Microsoft travaillent sur une extension de pilote en couches Vulkan. L’intention de l’extension VK_MSFT_layered_driver proposée est d’aider le chargeur Vulkan commun à mieux gérer la superposition des pilotes pour améliorer le tri des périphériques physiques. Voici leur énoncé de problème expliquant la situation que le pilote VK_MSFT_layered_driver encore à fusionner espère résoudre :
“Le chargeur Vulkan est capable de trier les périphériques physiques selon des critères spécifiques à la plate-forme. Par exemple, sous Windows, le chargeur utilise des LUID pour mettre les périphériques physiques dans le même ordre Cependant, il est possible d’avoir plusieurs pilotes Vulkan prenant en charge le même périphérique physique, l’un étant une implémentation”native”fournie par le fournisseur et l’autre une implémentation”en couches”au-dessus d’une API différente. des implémentations en couches incluraient VulkanOn12 (alias Dozen), en couches sur D3D12, et MoltenVK, en couches sur Metal.
Sur un système où un périphérique physique a deux pilotes possibles, l’ordre de tri entre eux n’est actuellement pas spécifié. Un ordre de tri idéal devrait placer tous les pilotes natifs/sans couches triés avant tous les pilotes en couches, car il faut s’attendre à ce que les pilotes natifs fournissent plus de fonctionnalités et de meilleures performances, car la superposition ajoute intrinsèquement une surcharge. Mais le chargeur n’a aucun moyen de savoir quel conducteur préférer.
Un problème supplémentaire qui n’est pas résolu par cette spécification est le cas où vous avez plusieurs pilotes”natifs”pour un seul périphérique physique. Dans ce cas, l’ordre de tri reste indéterminé, car un ordre correct entre les pilotes n’est pas évident.”
Du point de vue de Microsoft, ils essaient d’améliorer la gestion de leur propre pilote Mesa Dzn pour l’API Vulkan sur Direct3D 12. Comme indiqué, cette extension peut également être utile pour MoltenVK dans Vulkan sur l’API graphique/calcul Metal d’Apple.
Ceux qui sont intéressés par le travail d’extension de pilote en couches peuvent voir cette pull request pour les dernières discussions. En tout cas, c’est amusant de voir Microsoft préparer sa première contribution Vulkan.