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 at chromium.org>
> wrote:
>
>> On Tue 04 Apr 2017, Keith Packard wrote:
>>> Jason Ekstrand <jason at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel