From: Chad Versace <chadversary@chromium.org>
To: "\"Keith Packard\"" <keithp@keithp.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: Vulkan WSI+VK_KHR_display for KMS/DRM?
Date: Mon, 3 Apr 2017 12:44:55 -0700 [thread overview]
Message-ID: <20170403194455.GA58999@chadversary.pdx.corp.google.com> (raw)
In-Reply-To: <86o9wgkbr1.fsf@hiro.keithp.com>
On Fri 31 Mar 2017, "Keith Packard" wrote:
>
> Krh hacked up kmscube into vkcube which can run vulkan directly on kms,
> but that doesn't use any of the WSI apis and VK_KHR_display
> extension. Is anyone thinking that might be a good idea to do, or should
> we just keep on hacking things like vkcube does?
Don't rely on vkCreateDmaBufImageINTEL(). That's a relic from the Vulkan
pre-1.0 days, before WSI even existed! It helped during the driver
bootstrap process as a back door for dma_bufs, but it was never intended
to be a public interface. Both me and Jason Ekstrand have recently
submitted Mesa patches that delete it.
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.
Opaque fd fits well in the proprietary graphics ecosystem, but doesn't
fit so well with Linux graphics. So I'm working a dma_buf Vulkan
extension that adds VK_EXTERNAL_MEMORY_HANDLE_DMA_BUF_MESAX. You can
find a working vkcube demo here
<https://lists.freedesktop.org/archives/mesa-dev/2017-March/146827.html>.
The extension api in that demo isn't the final api, so please don't
flinch too hard :) I'm working on some spec changes before I submit the
next RFC.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-04-03 19:44 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 [this message]
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
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=20170403194455.GA58999@chadversary.pdx.corp.google.com \
--to=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.