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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
