* Vulkan WSI+VK_KHR_display for KMS/DRM? @ 2017-04-01 4:11 "Keith Packard" 2017-04-03 19:44 ` Chad Versace 0 siblings, 1 reply; 9+ messages in thread From: "Keith Packard" @ 2017-04-01 4:11 UTC (permalink / raw) To: dri-devel [-- Attachment #1.1: Type: text/plain, Size: 275 bytes --] 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? -- -keith [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Vulkan WSI+VK_KHR_display for KMS/DRM? 2017-04-01 4:11 Vulkan WSI+VK_KHR_display for KMS/DRM? "Keith Packard" @ 2017-04-03 19:44 ` Chad Versace 2017-04-03 19:56 ` Keith Packard 0 siblings, 1 reply; 9+ messages in thread From: Chad Versace @ 2017-04-03 19:44 UTC (permalink / raw) To: "Keith Packard"; +Cc: Jason Ekstrand, dri-devel 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Vulkan WSI+VK_KHR_display for KMS/DRM? 2017-04-03 19:44 ` Chad Versace @ 2017-04-03 19:56 ` Keith Packard 2017-04-04 14:45 ` Jason Ekstrand 0 siblings, 1 reply; 9+ messages in thread From: Keith Packard @ 2017-04-03 19:56 UTC (permalink / raw) To: Chad Versace; +Cc: Jason Ekstrand, dri-devel [-- Attachment #1.1: Type: text/plain, Size: 579 bytes --] Chad Versace <chadversary@chromium.org> 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? -- -keith [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Vulkan WSI+VK_KHR_display for KMS/DRM? 2017-04-03 19:56 ` Keith Packard @ 2017-04-04 14:45 ` Jason Ekstrand 2017-04-04 15:40 ` Keith Packard 2017-04-11 2:57 ` Michel Dänzer 0 siblings, 2 replies; 9+ messages in thread From: Jason Ekstrand @ 2017-04-04 14:45 UTC (permalink / raw) To: Keith Packard; +Cc: Chad Versace, dri-devel [-- Attachment #1.1: Type: text/plain, Size: 1206 bytes --] On Mon, Apr 3, 2017 at 12:56 PM, Keith Packard <keithp@keithp.com> wrote: > Chad Versace <chadversary@chromium.org> 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. :-) [-- Attachment #1.2: Type: text/html, Size: 1727 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Vulkan WSI+VK_KHR_display for KMS/DRM? 2017-04-04 14:45 ` Jason Ekstrand @ 2017-04-04 15:40 ` Keith Packard 2017-04-10 19:29 ` Chad Versace 2017-04-11 2:57 ` Michel Dänzer 1 sibling, 1 reply; 9+ messages in thread From: Keith Packard @ 2017-04-04 15:40 UTC (permalink / raw) To: Jason Ekstrand; +Cc: Chad Versace, dri-devel [-- Attachment #1.1: Type: text/plain, Size: 590 bytes --] Jason Ekstrand <jason@jlekstrand.net> writes: > 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. Sounds good, and minimizes the amount of code I have to write too :-) > I see no good reason to have a large abstraction in > the middle. Other than 'it's a standard', neither do I. -- -keith [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Vulkan WSI+VK_KHR_display for KMS/DRM? 2017-04-04 15:40 ` Keith Packard @ 2017-04-10 19:29 ` Chad Versace 2017-04-10 19:32 ` Jason Ekstrand 0 siblings, 1 reply; 9+ messages in thread From: Chad Versace @ 2017-04-10 19:29 UTC (permalink / raw) To: Keith Packard; +Cc: dri-devel, Jason Ekstrand On Tue 04 Apr 2017, Keith Packard wrote: > Jason Ekstrand <jason@jlekstrand.net> writes: > > > 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. > > Sounds good, and minimizes the amount of code I have to write too :-) I found an implementation. Nvidia's 2017-04-06 Linux driver release notes claim newly added support for VK_EXT_direct_mode_diplay, which is layered atop VK_KHR_display. http://www.nvidia.com/download/driverResults.aspx/117741/en-us https://www.khronos.org/registry/vulkan/specs/1.0-extensions/html/vkspec.html#VK_EXT_direct_mode_display > > I see no good reason to have a large abstraction in > > the middle. > > Other than 'it's a standard', neither do I. Yup. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Vulkan WSI+VK_KHR_display for KMS/DRM? 2017-04-10 19:29 ` Chad Versace @ 2017-04-10 19:32 ` Jason Ekstrand 2017-04-11 15:05 ` James Jones 0 siblings, 1 reply; 9+ messages in thread From: Jason Ekstrand @ 2017-04-10 19:32 UTC (permalink / raw) To: Chad Versace, Keith Packard; +Cc: dri-devel On April 10, 2017 12:29:12 PM Chad Versace <chadversary@chromium.org> wrote: > On Tue 04 Apr 2017, Keith Packard wrote: >> Jason Ekstrand <jason@jlekstrand.net> writes: >> >> > 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. >> >> Sounds good, and minimizes the amount of code I have to write too :-) > > I found an implementation. Nvidia's 2017-04-06 Linux driver release > notes claim newly added support for VK_EXT_direct_mode_diplay, which is > layered atop VK_KHR_display. If it's useful to do so, we can always pull Keith's work into Mesa or even put it in a layer. Let's start with an implementation and figure out the Vulkan bits later. Of there's something interesting in NVIDIA's extensions, we can let that guide the design of course. > http://www.nvidia.com/download/driverResults.aspx/117741/en-us > https://www.khronos.org/registry/vulkan/specs/1.0-extensions/html/vkspec.html#VK_EXT_direct_mode_display > >> > I see no good reason to have a large abstraction in >> > the middle. >> >> Other than 'it's a standard', neither do I. > > Yup. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Vulkan WSI+VK_KHR_display for KMS/DRM? 2017-04-10 19:32 ` Jason Ekstrand @ 2017-04-11 15:05 ` James Jones 0 siblings, 0 replies; 9+ messages in thread From: James Jones @ 2017-04-11 15:05 UTC (permalink / raw) To: Jason Ekstrand, Chad Versace, Keith Packard; +Cc: dri-devel On 04/10/2017 12:32 PM, Jason Ekstrand wrote: > On April 10, 2017 12:29:12 PM Chad Versace <chadversary@chromium.org> > wrote: > >> On Tue 04 Apr 2017, Keith Packard wrote: >>> Jason Ekstrand <jason@jlekstrand.net> writes: >>> >>> > 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. >>> >>> Sounds good, and minimizes the amount of code I have to write too :-) >> >> I found an implementation. Nvidia's 2017-04-06 Linux driver release >> notes claim newly added support for VK_EXT_direct_mode_diplay, which is >> layered atop VK_KHR_display. > > If it's useful to do so, we can always pull Keith's work into Mesa or > even put it in a layer. Let's start with an implementation and figure > out the Vulkan bits later. Of there's something interesting in NVIDIA's > extensions, we can let that guide the design of course. > >> http://www.nvidia.com/download/driverResults.aspx/117741/en-us >> https://www.khronos.org/registry/vulkan/specs/1.0-extensions/html/vkspec.html#VK_EXT_direct_mode_display >> >> >>> > I see no good reason to have a large abstraction in >>> > the middle. >>> >>> Other than 'it's a standard', neither do I. >> >> Yup. There's one good technical reason, at least on NVIDIA HW but I suspect others, and it's the same reason that spawned the EGLStream Vs. raw DRM-KMS debate: dma-buf+KMS doesn't let you transition to the VK_IMAGE_LAYOUT_PRESENT_SRC_KHR layout, so rendering to/texturing from the dma-buf images won't be as optimal as rendering to VK_KHR_display images. You could solve that (and I intend to) with the combination of Vulkan + the generic allocator stuff we started discussing at XDC last year, but it'll take more work. No, I haven't stopped working on that, I just haven't had much time for it lately. I'll have updates from my side there soon. Besides that, the abstraction's primary purpose is the same as any abstraction: portability. Applications targeting it will work on platforms that don't have DRM-KMS. That's more useful if there's a DRM-KMS implementation too. I fully expect that you could implement it via a Vulkan implicit layer as suggested here once the external memory and dma-buf stuff is complete, and there'd be nothing sub-optimal about that if you could properly transition the layouts. Nothing wrong with that implementation path. It also shouldn't be a lot of code to add a native DRM-KMS implementation in Mesa and then lift it to a layer later, or write it as a Vulkan layer now and add optimization once the generic allocator + Vulkan interactions are worked out. Clean interaction with DRM-KMS was one of the goals of the spec. I know of two (maybe three, but I haven't confirmed the last) other shipping implementations besides ours BTW, so this isn't a de-facto NVIDIA-ism dressed up like a standard. I don't think the other implementations are currently publicly available. Thanks, -James > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Vulkan WSI+VK_KHR_display for KMS/DRM? 2017-04-04 14:45 ` Jason Ekstrand 2017-04-04 15:40 ` Keith Packard @ 2017-04-11 2:57 ` Michel Dänzer 1 sibling, 0 replies; 9+ messages in thread From: Michel Dänzer @ 2017-04-11 2:57 UTC (permalink / raw) To: Jason Ekstrand, Keith Packard; +Cc: Chad Versace, dri-devel On 04/04/17 11:45 PM, Jason Ekstrand wrote: > On Mon, Apr 3, 2017 at 12:56 PM, Keith Packard <keithp@keithp.com > <mailto:keithp@keithp.com>> wrote: > > Chad Versace <chadversary@chromium.org > <mailto:chadversary@chromium.org>> 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-04-11 15:09 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-01 4:11 Vulkan WSI+VK_KHR_display for KMS/DRM? "Keith Packard" 2017-04-03 19:44 ` Chad Versace 2017-04-03 19:56 ` Keith Packard 2017-04-04 14:45 ` Jason Ekstrand 2017-04-04 15:40 ` Keith Packard 2017-04-10 19:29 ` Chad Versace 2017-04-10 19:32 ` Jason Ekstrand 2017-04-11 15:05 ` James Jones 2017-04-11 2:57 ` Michel Dänzer
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.