From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jason Ekstrand <jason@jlekstrand.net>
Subject: Re: Vulkan WSI+VK_KHR_display for KMS/DRM?
Date: Tue, 4 Apr 2017 07:45:38 -0700
Message-ID: <CAOFGe94DtfmkugO2TocjhRe+dREa67mFgavsaVQc_TBqvB5CEw@mail.gmail.com>
References: <86o9wgkbr1.fsf@hiro.keithp.com>
 <20170403194455.GA58999@chadversary.pdx.corp.google.com>
 <86pogtgt88.fsf@hiro.keithp.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1776270564=="
Return-path: <dri-devel-bounces@lists.freedesktop.org>
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com
 [IPv6:2a00:1450:400c:c09::22a])
 by gabe.freedesktop.org (Postfix) with ESMTPS id B23726E0AA
 for <dri-devel@lists.freedesktop.org>; Tue,  4 Apr 2017 14:45:40 +0000 (UTC)
Received: by mail-wm0-x22a.google.com with SMTP id x89so334077wma.0
 for <dri-devel@lists.freedesktop.org>; Tue, 04 Apr 2017 07:45:40 -0700 (PDT)
In-Reply-To: <86pogtgt88.fsf@hiro.keithp.com>
List-Unsubscribe: <https://lists.freedesktop.org/mailman/options/dri-devel>,
 <mailto:dri-devel-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <https://lists.freedesktop.org/archives/dri-devel>
List-Post: <mailto:dri-devel@lists.freedesktop.org>
List-Help: <mailto:dri-devel-request@lists.freedesktop.org?subject=help>
List-Subscribe: <https://lists.freedesktop.org/mailman/listinfo/dri-devel>,
 <mailto:dri-devel-request@lists.freedesktop.org?subject=subscribe>
Errors-To: dri-devel-bounces@lists.freedesktop.org
Sender: "dri-devel" <dri-devel-bounces@lists.freedesktop.org>
To: Keith Packard <keithp@keithp.com>
Cc: Chad Versace <chadversary@chromium.org>, dri-devel <dri-devel@lists.freedesktop.org>
List-Id: dri-devel@lists.freedesktop.org

--===============1776270564==
Content-Type: multipart/alternative; boundary=001a1145b9285778a0054c585405

--001a1145b9285778a0054c585405
Content-Type: text/plain; charset=UTF-8

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. :-)

--001a1145b9285778a0054c585405
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 3, 2017 at 12:56 PM, Keith Packard <span dir=3D"ltr">&lt;<a href=3D=
"mailto:keithp@keithp.com" target=3D"_blank">keithp@keithp.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span class=3D"">Chad Versace &=
lt;<a href=3D"mailto:chadversary@chromium.org">chadversary@chromium.org</a>=
&gt; writes:<br>
<br>
&gt; The real path forward should be implemented on top of<br>
&gt; VK_KHX_external_memory. If you want to start experimenting now with<br=
>
&gt; Vulkan+KMS, you may want to look at<br>
&gt; VK_EXTERNAL_MEMORY_HANDLE_<wbr>OPAQUE_FD_KHX.<br>
<br>
</span>It seems like the Vulkan spec for WSI with devices has a bunch of wh=
at I<br>
would need to implement in a standard fashion; I guess I&#39;m unclear<br>
whether I should go down the route of wrapping all of DRM/KMS in a WSI<br>
layer, or use some of this lower-level stuff directly from the<br>
application instead?<span class=3D"HOEnZb"><font color=3D"#888888"><br>
</font></span></blockquote></div><br></div><div class=3D"gmail_extra">Inter=
esting question.=C2=A0 To my knowledge, no one has actually implemented the=
 Vulkan WSI direct-to-display extensions.=C2=A0 (I tried to prevent them fr=
om getting released with 1.0 but failed.)=C2=A0 I believe the correct answe=
r is to use the external memory dma-buf stuff that chad and I have been usi=
ng and talk directly to KMS.=C2=A0 I see no good reason to have a large abs=
traction in the middle.=C2=A0 dma-buf + KMS should give you Intel and radeo=
n (with radv) so that&#39;s most of it.=C2=A0 In particular, it will give y=
ou 100% of people who actually care about DRM leases. :-)<br></div></div>

--001a1145b9285778a0054c585405--

--===============1776270564==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs
IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz
dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg==

--===============1776270564==--