Microsoft Preparing For Their First Vulkan Extension
While the Vulkan high performance graphics and compute API is backed by many vendors, Microsoft and Apple are two notable organizations that haven't backed this Khronos Group standard. For Microsoft's part, they obviously prefer their in-house Direct3D. However, Microsoft is making preparations for submitting their first Vulkan extension.
As part of the preparations for submitting their first Vulkan extension, overnight there was a merge to the Vulkan specification repository for adding the "MSFT" vendor prefix.
The vk.xml now has a MSFT tag for representing any Microsoft Corporation extensions moving forward.
Microsoft engineers are working on a Vulkan layered driver extension. The intent with the proposed VK_MSFT_layered_driver extension is to help the common Vulkan loader better deal with driver layering for improving the physical device sorting. Here's their problem statement explaining the situation that the yet-to-be-merged VK_MSFT_layered_driver hopes to address:
From Microsoft's perspective, they are trying to improve the handling of their own Mesa Dzn driver for Vulkan API atop Direct3D 12. As stated, this extension may also be helpful too for MoltenVK in Vulkan atop Apple's Metal graphics/compute API.
Those interested in the layered driver extension work can see this pull request for the latest discussions. In any event, it's fun seeing Microsoft preparing their first Vulkan contribution.
As part of the preparations for submitting their first Vulkan extension, overnight there was a merge to the Vulkan specification repository for adding the "MSFT" vendor prefix.
The vk.xml now has a MSFT tag for representing any Microsoft Corporation extensions moving forward.
Microsoft engineers are working on a Vulkan layered driver extension. The intent with the proposed VK_MSFT_layered_driver extension is to help the common Vulkan loader better deal with driver layering for improving the physical device sorting. Here's their problem statement explaining the situation that the yet-to-be-merged VK_MSFT_layered_driver hopes to address:
"The Vulkan loader is able to sort physical devices according to platform-specific criteria. For example, on Windows, the loader uses LUIDs to put physical devices in the same order as DXGI adapters. However, it is possible to have multiple Vulkan drivers that provide support for the same physical device, where one is a "native" vendor-provided implementation and another is a "layered" implementation on top of a different API. Examples of layered implementations would include VulkanOn12 (aka Dozen), layered on D3D12, and MoltenVK, layered on Metal.
On a system where a physical device has two possible drivers, the sort order between them is currently unspecified. An ideal sort order should place any native/un-layered drivers sorted-before any layered drivers, as it should be expected that native drivers will provide more functionality and higher performance, since layering inherently adds overhead. But the loader has no way of knowing which driver to prefer.
An additional problem that is not addressed by this specification is the case where you have multiple "native" drivers for a single physical device. In that case, the sort order remains unspecified, as a correct ordering between drivers is non-obvious."
From Microsoft's perspective, they are trying to improve the handling of their own Mesa Dzn driver for Vulkan API atop Direct3D 12. As stated, this extension may also be helpful too for MoltenVK in Vulkan atop Apple's Metal graphics/compute API.
Those interested in the layered driver extension work can see this pull request for the latest discussions. In any event, it's fun seeing Microsoft preparing their first Vulkan contribution.
18 Comments