Vulkan WSI+VK_KHR_display for KMS/DRM?

Vulkan WSI+VK_KHR_display for KMS/DRM?

["Keith Packard"]

[-- 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

Re: Vulkan WSI+VK_KHR_display for KMS/DRM?

[Chad Versace]

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

Re: Vulkan WSI+VK_KHR_display for KMS/DRM?

[Keith Packard]

[-- 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

Re: Vulkan WSI+VK_KHR_display for KMS/DRM?

[Jason Ekstrand]

[-- 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

Re: Vulkan WSI+VK_KHR_display for KMS/DRM?

[Keith Packard]

[-- 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

Re: Vulkan WSI+VK_KHR_display for KMS/DRM?

[Chad Versace]

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

Re: Vulkan WSI+VK_KHR_display for KMS/DRM?

[Jason Ekstrand]

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

Re: Vulkan WSI+VK_KHR_display for KMS/DRM?

[Michel Dänzer]

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

Re: Vulkan WSI+VK_KHR_display for KMS/DRM?

[James Jones]

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