On 04/04/17 11:45 PM, Jason Ekstrand wrote: > On Mon, Apr 3, 2017 at 12:56 PM, Keith Packard <keithp@xxxxxxxxxx > <mailto:keithp@xxxxxxxxxx>> wrote: > > Chad Versace <chadversary@xxxxxxxxxxxx > <mailto:chadversary@xxxxxxxxxxxx>> writes: > > > 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. > > It seems like the Vulkan spec for WSI with devices has a bunch of what I > would need to implement in a standard fashion; I guess I'm unclear > whether I should go down the route of wrapping all of DRM/KMS in a WSI > layer, or use some of this lower-level stuff directly from the > application instead? > > > Interesting question. To my knowledge, no one has actually implemented > the Vulkan WSI direct-to-display extensions. (I tried to prevent them > from getting released with 1.0 but failed.) I believe the correct > answer is to use the external memory dma-buf stuff that chad and I have > been using and talk directly to KMS. I see no good reason to have a > large abstraction in the middle. dma-buf + KMS should give you Intel > and radeon (with radv) so that's most of it. In particular, it will > give you 100% of people who actually care about DRM leases. :-) FWIW, there's no fundamental reason why this couldn't work with AMD's Vulkan driver (currently only available as part of the amdgpu-pro stack) either. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
