All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel@daenzer.net>
To: Jason Ekstrand <jason@jlekstrand.net>, Keith Packard <keithp@keithp.com>
Cc: Chad Versace <chadversary@chromium.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: Vulkan WSI+VK_KHR_display for KMS/DRM?
Date: Tue, 11 Apr 2017 11:57:56 +0900	[thread overview]
Message-ID: <dd42bc80-9ce1-d0af-2106-04beb91c88ac@daenzer.net> (raw)
In-Reply-To: <CAOFGe94DtfmkugO2TocjhRe+dREa67mFgavsaVQc_TBqvB5CEw@mail.gmail.com>

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

      parent reply	other threads:[~2017-04-11  2:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-01  4:11 Vulkan WSI+VK_KHR_display for KMS/DRM? "Keith Packard"
2017-04-03 19:44 ` Chad Versace
2017-04-03 19:56   ` Keith Packard
2017-04-04 14:45     ` Jason Ekstrand
2017-04-04 15:40       ` Keith Packard
2017-04-10 19:29         ` Chad Versace
2017-04-10 19:32           ` Jason Ekstrand
2017-04-11 15:05             ` James Jones
2017-04-11  2:57       ` Michel Dänzer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dd42bc80-9ce1-d0af-2106-04beb91c88ac@daenzer.net \
    --to=michel@daenzer.net \
    --cc=chadversary@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jason@jlekstrand.net \
    --cc=keithp@keithp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.