Vulkan WSI+VK_KHR_display for KMS/DRM?

Chad Versace chadversary at chromium.org
Mon Apr 3 19:44:55 UTC 2017


On Fri 31 Mar 2017, "Keith Packard" wrote:
> 
> Krh hacked up kmscube into vkcube which can run vulkan directly on kms,
> but that doesn't use any of the WSI apis and VK_KHR_display
> extension. Is anyone thinking that might be a good idea to do, or should
> we just keep on hacking things like vkcube does?

Don't rely on vkCreateDmaBufImageINTEL(). That's a relic from the Vulkan
pre-1.0 days, before WSI even existed! It helped during the driver
bootstrap process as a back door for dma_bufs, but it was never intended
to be a public interface. Both me and Jason Ekstrand have recently
submitted Mesa patches that delete it.

The real path forward should be implemented on top of
VK_KHX_external_memory. If you want to start experimenting now with
Vulkan+KMS, you may want to look at VK_EXTERNAL_MEMORY_HANDLE_OPAQUE_FD_KHX.

Opaque fd fits well in the proprietary graphics ecosystem, but doesn't
fit so well with Linux graphics. So I'm working a dma_buf Vulkan
extension that adds VK_EXTERNAL_MEMORY_HANDLE_DMA_BUF_MESAX. You can
find a working vkcube demo here
<https://lists.freedesktop.org/archives/mesa-dev/2017-March/146827.html>.

The extension api in that demo isn't the final api, so please don't
flinch too hard :) I'm working on some spec changes before I submit the
next RFC.


More information about the dri-devel mailing list