Si bien la API de cómputo y gráficos de alto rendimiento de Vulkan está respaldada por muchos proveedores, Microsoft y Apple son dos organizaciones notables que no han respaldado este estándar del Grupo Khronos. Por parte de Microsoft, obviamente prefieren su Direct3D interno. Sin embargo, Microsoft se está preparando para enviar su primera extensión Vulkan.
Como parte de los preparativos para enviar su primera extensión de Vulkan, de la noche a la mañana hubo una fusión con la Repositorio de especificaciones de Vulkan para agregar el prefijo de proveedor”MSFT”.
El vk.xml ahora tiene una etiqueta MSFT para representar cualquier extensión de Microsoft Corporation en el futuro.
Los ingenieros de Microsoft están trabajando en una extensión de controlador en capas de Vulkan. La intención de la extensión VK_MSFT_layered_driver propuesta es ayudar al cargador Vulkan común a lidiar mejor con las capas de controladores para mejorar la clasificación de dispositivos físicos. Aquí está la declaración del problema que explica la situación que el VK_MSFT_layered_driver aún por fusionar espera abordar:
“El cargador Vulkan puede ordenar los dispositivos físicos de acuerdo con los criterios específicos de la plataforma. Por ejemplo, en Windows, el cargador usa LUID para colocar los dispositivos físicos en el mismo orden como adaptadores DXGI Sin embargo, es posible tener varios controladores Vulkan que brinden soporte para el mismo dispositivo físico, donde uno es una implementación”nativa”proporcionada por el proveedor y otro es una implementación”en capas”sobre una API diferente. Ejemplos de implementaciones en capas incluiría VulkanOn12 (también conocido como Dozen), en capas en D3D12, y MoltenVK, en capas en Metal.
En un sistema donde un dispositivo físico tiene dos controladores posibles, el orden de clasificación entre ellos no está especificado actualmente. Un orden de clasificación ideal debe colocar los controladores nativos/sin capas ordenados antes de los controladores con capas, ya que se debe esperar que los controladores nativos brinden más funcionalidad y un mayor rendimiento, ya que las capas inherentemente agregan sobrecarga. Pero el cargador no tiene forma de saber qué conductor preferir.
Un problema adicional que no se aborda en esta especificación es el caso en el que tiene varios controladores”nativos”para un solo dispositivo físico. En ese caso, el orden de clasificación permanece sin especificar, ya que no es obvio un orden correcto entre los controladores”.
Desde la perspectiva de Microsoft, están tratando de mejorar el manejo de su propio controlador Mesa Dzn. para la API de Vulkan sobre Direct3D 12. Como se indicó, esta extensión también puede ser útil para MoltenVK en Vulkan sobre la API de computación/gráficos Metal de Apple.
Aquellos interesados en el trabajo de extensión del controlador en capas pueden ver esta solicitud de incorporación de cambios para ver las discusiones más recientes. En cualquier caso, es divertido ver a Microsoft preparando su primera contribución de Vulkan.