On 04/10/2017 12:32 PM, Jason Ekstrand wrote:
On April 10, 2017 12:29:12 PM Chad Versace <chadversary@xxxxxxxxxxxx>
wrote:
On Tue 04 Apr 2017, Keith Packard wrote:
Jason Ekstrand <jason@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
