Vulkan WSI+VK_KHR_display for KMS/DRM?
jajones at nvidia.com
Tue Apr 11 15:05:54 UTC 2017
On 04/10/2017 12:32 PM, Jason Ekstrand wrote:
> On April 10, 2017 12:29:12 PM Chad Versace <chadversary at chromium.org>
>> 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
>>> > 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.
>>> > I see no good reason to have a large abstraction in
>>> > the middle.
>>> Other than 'it's a standard', neither do I.
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
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
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.
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
More information about the dri-devel