RE: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

2018-03-29 Thread Keith Packard 
"Mao, David"  writes:

> Hi Keith,
> If I read the patch correctly, the plane has been interpreted as the same as 
> connector, and the stackIndex is the index of connector of current device.
> Is it by intentional?
> If the hardware don't have underlay/overlay supported, is it better to
> always report plane 0 rather than pretend to have multiple plane?

Yes, you're right. I must have mis-read the specification when writing
this function. Thanks for catching this. I've merged this fix into the
patch and re-pushed it to my drm-lease-v2 branch.

-- 
-keith


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

2018-03-29 Thread Mao, David 
Hi Keith,
If I read the patch correctly, the plane has been interpreted as the same as 
connector, and the stackIndex is the index of connector of current device.
Is it by intentional?
If the hardware don't have underlay/overlay supported, is it better to always 
report plane 0 rather than pretend to have multiple plane?

Thanks.
Best Regards,
David

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Keith Packard
Sent: Saturday, February 10, 2018 12:45 PM
To: mesa-...@lists.freedesktop.org
Cc: Keith Packard ; dri-devel@lists.freedesktop.org
Subject: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

This adds support for the KHR_display extension to the anv and radv
Vulkan drivers. The drivers now attempt to open the master DRM node
when the KHR_display extension is requested so that the common winsys
code can perform the necessary operations.

Signed-off-by: Keith Packard 
---
 configure.ac   |1 +
 meson.build|4 +-
 src/amd/vulkan/Makefile.am |8 +
 src/amd/vulkan/Makefile.sources|3 +
 src/amd/vulkan/meson.build |7 +
 src/amd/vulkan/radv_device.c   |   28 +-
 src/amd/vulkan/radv_extensions.py  |7 +-
 src/amd/vulkan/radv_private.h  |2 +
 src/amd/vulkan/radv_wsi.c  |3 +-
 src/amd/vulkan/radv_wsi_display.c  |  143 
 src/intel/Makefile.sources |3 +
 src/intel/Makefile.vulkan.am   |7 +
 src/intel/vulkan/anv_device.c  |   18 +-
 src/intel/vulkan/anv_extensions.py |1 +
 src/intel/vulkan/anv_extensions_gen.py |5 +-
 src/intel/vulkan/anv_wsi.c |3 +-
 src/intel/vulkan/anv_wsi_display.c |  129 +++
 src/intel/vulkan/meson.build   |7 +
 src/vulkan/Makefile.am |7 +
 src/vulkan/Makefile.sources|4 +
 src/vulkan/wsi/meson.build |   10 +
 src/vulkan/wsi/wsi_common.c|   19 +-
 src/vulkan/wsi/wsi_common.h|5 +-
 src/vulkan/wsi/wsi_common_display.c| 1368 
 src/vulkan/wsi/wsi_common_display.h|   72 ++
 src/vulkan/wsi/wsi_common_private.h|   10 +
 26 files changed, 1858 insertions(+), 16 deletions(-)
 create mode 100644 src/amd/vulkan/radv_wsi_display.c
 create mode 100644 src/intel/vulkan/anv_wsi_display.c
 create mode 100644 src/vulkan/wsi/wsi_common_display.c
 create mode 100644 src/vulkan/wsi/wsi_common_display.h

diff --git a/configure.ac b/configure.ac
index 8ed606c7694..46318365603 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1849,6 +1849,7 @@ fi
 AM_CONDITIONAL(HAVE_PLATFORM_X11, echo "$platforms" | grep -q 'x11')
 AM_CONDITIONAL(HAVE_PLATFORM_WAYLAND, echo "$platforms" | grep -q 'wayland')
 AM_CONDITIONAL(HAVE_PLATFORM_DRM, echo "$platforms" | grep -q 'drm')
+AM_CONDITIONAL(HAVE_PLATFORM_DISPLAY, echo "$platforms" | grep -q 'drm')
 AM_CONDITIONAL(HAVE_PLATFORM_SURFACELESS, echo "$platforms" | grep -q 
'surfaceless')
 AM_CONDITIONAL(HAVE_PLATFORM_ANDROID, echo "$platforms" | grep -q 'android')
 
diff --git a/meson.build b/meson.build
index b39e2f8ab96..aeb7f5e2917 100644
--- a/meson.build
+++ b/meson.build
@@ -239,11 +239,12 @@ with_platform_wayland = false
 with_platform_x11 = false
 with_platform_drm = false
 with_platform_surfaceless = false
+with_platform_display = false
 egl_native_platform = ''
 _platforms = get_option('platforms')
 if _platforms == 'auto'
   if system_has_kms_drm
-_platforms = 'x11,wayland,drm,surfaceless'
+_platforms = 'x11,wayland,drm,surfaceless,display'
   elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
 _platforms = 'x11,surfaceless'
   else
@@ -257,6 +258,7 @@ if _platforms != ''
   with_platform_wayland = _split.contains('wayland')
   with_platform_drm = _split.contains('drm')
   with_platform_surfaceless = _split.contains('surfaceless')
+  with_platform_display = _split.contains('display')
   egl_native_platform = _split[0]
 endif
 
diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
index 61025968942..061b8144b88 100644
--- a/src/amd/vulkan/Makefile.am
+++ b/src/amd/vulkan/Makefile.am
@@ -76,6 +76,14 @@ VULKAN_LIB_DEPS = \
$(DLOPEN_LIBS) \
-lm
 
+if HAVE_PLATFORM_DISPLAY
+AM_CPPFLAGS += \
+   -DVK_USE_PLATFORM_DISPLAY_KHR
+
+VULKAN_SOURCES += $(VULKAN_WSI_DISPLAY_FILES)
+
+endif
+
 if HAVE_PLATFORM_X11
 AM_CPPFLAGS += \
$(XCB_DRI3_CFLAGS) \
diff --git a/src/amd/vulkan/Makefile.sources b/src/amd/vulkan/Makefile.sources
index a510d88d965..618a6cdaed0 100644
--- a/src/amd/vulkan/Makefile.sources
+++ b/src/amd/vulkan/Makefile.sources
@@ -78,6 +78,9 @@ VULKAN_WSI_WAYLAND_FILES := \
 VULKAN_WSI_X11_FILES := \
radv_wsi_x11.c
 
+VULKAN_WSI_DISPLAY_FILES := \
+   radv_wsi_display.c
+
 VULKAN_GENERATED_FILES := \
radv_entrypoints.c \

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

2018-03-12 Thread Keith Packard 
Jason Ekstrand  writes:

> On Fri, Feb 23, 2018 at 3:43 PM, Keith Packard  wrote:
>
> Once we're sure that's what we want, create an MR against the spec that
> just adds enough to the XML to reserve your extension number.  That will
> get merged almost immediately.  Then make a second one with the actual
> extension text and we'll iterate on that either in Khronos gitlab or, if
> you prefer, you can send it as a patch to mesa-dev and then make a Khrons
> MR once it's baked.

I just wrote up the full extension description for both extensions I
need (the one for passing a KMS fd to the driver, and the second to get
the GPU timestamp for doing GOOGLE_display_timing):

https://github.com/keith-packard/Vulkan-Docs

> See also my comments about GEM handle ownership.

Yeah, I think I've got that all cleaned up now -- the code no longer
shares the same file for rendering and display.

-- 
-keith


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

2018-02-23 Thread Jason Ekstrand 
On Fri, Feb 23, 2018 at 3:43 PM, Keith Packard  wrote:

> Jason Ekstrand  writes:
>
> > I think I like option 1 (KEITHP_kms_display).  If the client knows the
> > difference between render and primary for 2, then they are most likely
> > already opening the master node themselves or at least have access to
> > the FD.
>
> Ok, I'll work on cleaning up that extension and renaming it. I have no
> idea how to get new words into the Vulkan spec, but it would be good to
> have that done too.
>

Once we're sure that's what we want, create an MR against the spec that
just adds enough to the XML to reserve your extension number.  That will
get merged almost immediately.  Then make a second one with the actual
extension text and we'll iterate on that either in Khronos gitlab or, if
you prefer, you can send it as a patch to mesa-dev and then make a Khrons
MR once it's baked.


> I guess the question is whether I should bother to leave the current
> try-to-open-primary kludge in place. In good news, under X, both radv
> and anv "fail" to use the primary device as another master is already
> running, so at least we aren't running with a primary FD open?
>

See also my comments about GEM handle ownership.


> > Sorry, I'm just not feeling all that opinionated about this at the
> moment.
> > :-)
>
> No more than I; either way is fine with me, if you're happy to use
> something like the existing code I've got, that's even nicer.
>
> > Clearly, we need systemd-edidd. :-)
>
> A library would be nice; we have the edid data everywhere, we just don't
> have it in a useful form except inside the X server and kernel.
>

Yeah, in the scary new world of Wayland compositors, having an edid library
would be a very good thing.  No sense in having everyone fail to handle it
properly themselves.


> > Yes, *if* it has a preferred resolution, we should return that one.  If
> it
> > doesn't, we should walk the list and return the largest instead of just
> > defaulting to 1024x768.  At least that's what the spec seems to say to
> > me.
>
> Oh. I totally missed that part. Yeah, that's just wrong. I've just
> pushed a patch that finds the largest mode when there isn't a preferred
> one. Oddly, I have no devices here which don't specify a preferred mode,
> so it will be somewhat difficult to test...
>
> > Yup.  Let's just drop INHERIT and only advertise OPAQUE.
>
> Done.
>
> I've updated my drm-lease branch with all of these changes merged into
> the existing patches (and so noted), plus the new patch described above
> which looks for the largest mode when no preferred mode is specified.
>
> Thanks again for all of your careful review; while we haven't changed
> any significant semantics, we have found a bunch of outright bugs in the
> code.
>

Glad to help. :-)  I figure I should learn something about KMS one day and
reviewing this is as good an opportunity as any.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

2018-02-23 Thread Keith Packard 
Jason Ekstrand  writes:

> I think I like option 1 (KEITHP_kms_display).  If the client knows the
> difference between render and primary for 2, then they are most likely
> already opening the master node themselves or at least have access to
> the FD.

Ok, I'll work on cleaning up that extension and renaming it. I have no
idea how to get new words into the Vulkan spec, but it would be good to
have that done too.

I guess the question is whether I should bother to leave the current
try-to-open-primary kludge in place. In good news, under X, both radv
and anv "fail" to use the primary device as another master is already
running, so at least we aren't running with a primary FD open?

> Sorry, I'm just not feeling all that opinionated about this at the moment.
> :-)

No more than I; either way is fine with me, if you're happy to use
something like the existing code I've got, that's even nicer.

> Clearly, we need systemd-edidd. :-)

A library would be nice; we have the edid data everywhere, we just don't
have it in a useful form except inside the X server and kernel.

> Yes, *if* it has a preferred resolution, we should return that one.  If it
> doesn't, we should walk the list and return the largest instead of just
> defaulting to 1024x768.  At least that's what the spec seems to say to
> me.

Oh. I totally missed that part. Yeah, that's just wrong. I've just
pushed a patch that finds the largest mode when there isn't a preferred
one. Oddly, I have no devices here which don't specify a preferred mode,
so it will be somewhat difficult to test...

> Yup.  Let's just drop INHERIT and only advertise OPAQUE.

Done.

I've updated my drm-lease branch with all of these changes merged into
the existing patches (and so noted), plus the new patch described above
which looks for the largest mode when no preferred mode is specified.

Thanks again for all of your careful review; while we haven't changed
any significant semantics, we have found a bunch of outright bugs in the
code.

-- 
-keith


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

2018-02-23 Thread Jason Ekstrand 
On Thu, Feb 15, 2018 at 9:46 AM, Keith Packard  wrote:

> Jason Ekstrand  writes:
>
> > It seems a little odd to me to default to opening the master node and
> then
> > fall back to the render node if it doesn't work.  I suppose that's
> probably
> > ok so long as we ensure that vkGetPhysicalDeviceDisplayPropertiesKHR
> > returns no displays if we're on the render node.
> >
> > We could always go back to the DRM fd extension idea but I'm not coming
> up
> > with something nice and clean in the 60 seconds I've thought about it.
>
> As I said in the last comments about this section, Dave Airlie and I
> added this code only recently so that we could test this extension
> without also needing the kernel and X leasing changes.
>
> I think we should decide how to enable this functionality "for real",
> and I have two easy options:
>
>  1) Use my KEITHP_kms_display extension (presumably renamed MESA), which
> exposes a way to pass the DRM fd from the application into the
> driver. This makes it possible for the application to get the FD
> through any mechanism at all (including RandR or the new Wayland
> extension) and leave that out of the Vulkan code entirely.
>
>  2) Add a new extension which passes a new data structure that directs
> the driver to open either the Render or Primary nodes.
>
> When this is done, we can switch from the current code which tries to
> open the Primary node whenever the KHR_display extension is requested.
>

I think I like option 1.  If the client knows the difference between render
and primary for 2, then they are most likely already opening the master
node themselves or at least have access to the FD.

For an application that just wants to draw some stuff on the screen and is
ok with letting Vulkan fully handle KMS for it, the current code may be a
fine solution.

Sorry, I'm just not feeling all that opinionated about this at the moment.
:-)


> > Would it make anything easier if we just storred the DRM struct here?
> "No"
> > is a perfectly valid answer.
>
> Nope -- once we add the acquire_xlib extension, we get modes through
> either X or DRM, depending on whether we're pre-lease or post-lease.
>

Sounds good.


> > Any particular reason why the list of modes is global and not in the
> > connector?  It seems like it would be a tiny bit more efficient and
> > convenient to put the list in the connector.
>
> I think you're right. I have some vague memory of a lifetime issue with
> connectors, but can't think of what it might be, even after reviewing
> the relevant parts of the Vulkan spec. I've gone ahead and changed it;
> seems to work fine.
>
> >> +   LIST_FOR_EACH_ENTRY(display_mode, >display_modes, list)
> >> +  if (display_mode->connector == connector)
> >> + display_mode->valid = false;
> >>
> >
> > Please use braces for loops containing more than one line.
>
> Well, that was easy to fix -- the condition is now gone :-)
>

Even better!


> > Since we're allocating these in a physical device query, we need to use
> the
> > INSTANCE scope.  the OBJECT scope is intended for vkCreate functions to
> > allocated data that will live no longer than the associated vkDestroy
> > function.
>
> Thanks! The whole Vulkan memory model remains a mystery to me.
>
> I've changed allocation of wsi_display_mode and wsi_display_connector to
> use SCOPE_INSTANCE. VkIceSurfaceDisplay, wsi_display_fence and
> wsi_display_swapchain remain using SCOPE_OBJECT.
>

That sounds correct to me.


> I've also changed *all* instances of vk_alloc to use
> vk_zalloc. These are all small data structures allocated only during
> application startup, so I think the benefit of known memory contents is
> worth the cost of memset.
>
> > Hooray for obviously false fixed constants!
> >
> > I know the answer to this will be "EDIDs lie, never trust them!" but can
> we
> > get the real value somehow?  As someone who has a 13" laptop with a
> > 3200x1800 display, I know that number isn't always right. :-)
>
> Yes, we could dig the real value out of the EDID, but we'd have to parse
> the entire EDID to manage that. I don't want to stick an EDID parser
> directly in Mesa, so I'm kinda waiting for someone to create a separate
> EDID parsing library that the X server, Mesa and others can share. Until
> then, I'd prefer to just lie here.
>

Clearly, we need systemd-edidd. :-)


> > double-;;
>
> Thx. I remember seeing this while reviewing patches and forgot all about
> it...
>
> > From the Vulkan spec:
> >
> > Note:
> > For devices which have no natural value to return here,
> implementations
> > *should* return the maximum resolution supported.
> >
> > We should walk the list and pick the biggest one.
>
> I did this intentionally -- most monitors have a preferred resolution,
> which is their native pixel size. And, we want to tell applications to
> use that size, even if the monitor offers a larger (presumabl scaled)
> resolution in their mode

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

2018-02-15 Thread Keith Packard 
Jason Ekstrand  writes:

> It seems a little odd to me to default to opening the master node and then
> fall back to the render node if it doesn't work.  I suppose that's probably
> ok so long as we ensure that vkGetPhysicalDeviceDisplayPropertiesKHR
> returns no displays if we're on the render node.
>
> We could always go back to the DRM fd extension idea but I'm not coming up
> with something nice and clean in the 60 seconds I've thought about it.

As I said in the last comments about this section, Dave Airlie and I
added this code only recently so that we could test this extension
without also needing the kernel and X leasing changes.

I think we should decide how to enable this functionality "for real",
and I have two easy options:

 1) Use my KEITHP_kms_display extension (presumably renamed MESA), which
exposes a way to pass the DRM fd from the application into the
driver. This makes it possible for the application to get the FD
through any mechanism at all (including RandR or the new Wayland
extension) and leave that out of the Vulkan code entirely.

 2) Add a new extension which passes a new data structure that directs
the driver to open either the Render or Primary nodes.

When this is done, we can switch from the current code which tries to
open the Primary node whenever the KHR_display extension is requested.

> Would it make anything easier if we just storred the DRM struct here?  "No"
> is a perfectly valid answer.

Nope -- once we add the acquire_xlib extension, we get modes through
either X or DRM, depending on whether we're pre-lease or post-lease.

> Any particular reason why the list of modes is global and not in the
> connector?  It seems like it would be a tiny bit more efficient and
> convenient to put the list in the connector.

I think you're right. I have some vague memory of a lifetime issue with
connectors, but can't think of what it might be, even after reviewing
the relevant parts of the Vulkan spec. I've gone ahead and changed it;
seems to work fine.

>> +   LIST_FOR_EACH_ENTRY(display_mode, >display_modes, list)
>> +  if (display_mode->connector == connector)
>> + display_mode->valid = false;
>>
>
> Please use braces for loops containing more than one line.

Well, that was easy to fix -- the condition is now gone :-)

> Since we're allocating these in a physical device query, we need to use the
> INSTANCE scope.  the OBJECT scope is intended for vkCreate functions to
> allocated data that will live no longer than the associated vkDestroy
> function.

Thanks! The whole Vulkan memory model remains a mystery to me.

I've changed allocation of wsi_display_mode and wsi_display_connector to
use SCOPE_INSTANCE. VkIceSurfaceDisplay, wsi_display_fence and
wsi_display_swapchain remain using SCOPE_OBJECT.

I've also changed *all* instances of vk_alloc to use
vk_zalloc. These are all small data structures allocated only during
application startup, so I think the benefit of known memory contents is
worth the cost of memset.

> Hooray for obviously false fixed constants!
>
> I know the answer to this will be "EDIDs lie, never trust them!" but can we
> get the real value somehow?  As someone who has a 13" laptop with a
> 3200x1800 display, I know that number isn't always right. :-)

Yes, we could dig the real value out of the EDID, but we'd have to parse
the entire EDID to manage that. I don't want to stick an EDID parser
directly in Mesa, so I'm kinda waiting for someone to create a separate
EDID parsing library that the X server, Mesa and others can share. Until
then, I'd prefer to just lie here.

> double-;;

Thx. I remember seeing this while reviewing patches and forgot all about
it...

> From the Vulkan spec:
>
> Note:
> For devices which have no natural value to return here, implementations
> *should* return the maximum resolution supported.
>
> We should walk the list and pick the biggest one.

I did this intentionally -- most monitors have a preferred resolution,
which is their native pixel size. And, we want to tell applications to
use that size, even if the monitor offers a larger (presumabl scaled)
resolution in their mode list.

> See question about MM_PER_PIXEL above

Yeah, see response about not boiling the EDID ocean above ;-)

> I know i915 can do better at least in some cases.  Is there a practical way
> to expose this?  If not, I'm fine with just exposing IDENTITY.

I'm not seeing this exposed through the common DRM mode interfaces
yet. We should probably consider adding this to the kernel and then
adding it here.

> This error is not allowed for this function.  We should just write 0 to
> property_count and return VK_SUCCESS.  Maybe add some asserts for debug
> builds if you really think this shouldn't ever happen.

I bet it will happen if you VT switch away and then try this function.

I've added this at the end of the function:

bail:
   *property_count = 0;
   return VK_SUCCESS;

>

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

2018-02-12 Thread Keith Packard 
Eric Engestrom  writes:

> copy/paste error: s/drm/display/

That's actually intentional -- any system which supports 'drm' can
support the display backend as it's based on that. Maybe it should use a
different test? (note that I haven't been using the autotools backend
recently, so it may not be great at this point. At least my current tree
builds?)

>> +if with_platform_display
>> +  radv_flags += [
>> +'-DVK_USE_PLATFORM_DISPLAY_KHR',
>> +  ]
>
> Nit: this can be a simple
>   radv_flags += '-DVK_USE_PLATFORM_DISPLAY_KHR'
>
>> +if with_platform_display
>> +  vulkan_wsi_args += [
>> +'-DVK_USE_PLATFORM_DISPLAY_KHR',
>> +  ]
>
> Ditto:
>   vulkan_wsi_args += '-DVK_USE_PLATFORM_DISPLAY_KHR'


Oh, good point -- I'd split out the RANDR and DISPLAY bits but didn't
simplify the meson stuff.

> Nit: src/amd/vulkan/ uses tabs for indent, you used spaces.

Thanks; I'll reconfigure my environment so that it uses tabs in that
directory, and re-indent the changes.

>> +#define MM_PER_PIXEL (1.0/96.0 * 25.4)
>
> unused

Good catch; those got left in both anv and radv directories after some
refactoring.

>> +#if 0
>
> `#if DEBUG` maybe?

Could do; I could also just strip out the printf debugging, but when
you're doing timing-sensitive stuff at that level, printf debugging is
pretty useful.

>> +#define wsi_display_debug(...) fprintf(stderr, __VA_ARGS__)
>> +#define wsi_display_debug_code(...) __VA_ARGS__
>
> that 2nd one is unused

It gets used in a later patch.

>> +   if (wsi) {
>
> if (!wsi) return;
> and carry on without the extra indent

Yeah, would probably look cleaner.

> I don't know enough for this to be an actual review though, but the rest
> of this file looks reasonable to me :)

Thanks for reviewing the basic formatting and structure though; I
totally missed the tabs/spaces issue.

-- 
-keith


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

2018-02-12 Thread Eric Engestrom 
On Friday, 2018-02-09 20:45:10 -0800, Keith Packard wrote:
> This adds support for the KHR_display extension to the anv and radv
> Vulkan drivers. The drivers now attempt to open the master DRM node
> when the KHR_display extension is requested so that the common winsys
> code can perform the necessary operations.
> 
> Signed-off-by: Keith Packard 
> ---
>  configure.ac   |1 +
>  meson.build|4 +-
>  src/amd/vulkan/Makefile.am |8 +
>  src/amd/vulkan/Makefile.sources|3 +
>  src/amd/vulkan/meson.build |7 +
>  src/amd/vulkan/radv_device.c   |   28 +-
>  src/amd/vulkan/radv_extensions.py  |7 +-
>  src/amd/vulkan/radv_private.h  |2 +
>  src/amd/vulkan/radv_wsi.c  |3 +-
>  src/amd/vulkan/radv_wsi_display.c  |  143 
>  src/intel/Makefile.sources |3 +
>  src/intel/Makefile.vulkan.am   |7 +
>  src/intel/vulkan/anv_device.c  |   18 +-
>  src/intel/vulkan/anv_extensions.py |1 +
>  src/intel/vulkan/anv_extensions_gen.py |5 +-
>  src/intel/vulkan/anv_wsi.c |3 +-
>  src/intel/vulkan/anv_wsi_display.c |  129 +++
>  src/intel/vulkan/meson.build   |7 +
>  src/vulkan/Makefile.am |7 +
>  src/vulkan/Makefile.sources|4 +
>  src/vulkan/wsi/meson.build |   10 +
>  src/vulkan/wsi/wsi_common.c|   19 +-
>  src/vulkan/wsi/wsi_common.h|5 +-
>  src/vulkan/wsi/wsi_common_display.c| 1368 
> 
>  src/vulkan/wsi/wsi_common_display.h|   72 ++
>  src/vulkan/wsi/wsi_common_private.h|   10 +
>  26 files changed, 1858 insertions(+), 16 deletions(-)
>  create mode 100644 src/amd/vulkan/radv_wsi_display.c
>  create mode 100644 src/intel/vulkan/anv_wsi_display.c
>  create mode 100644 src/vulkan/wsi/wsi_common_display.c
>  create mode 100644 src/vulkan/wsi/wsi_common_display.h
> 
> diff --git a/configure.ac b/configure.ac
> index 8ed606c7694..46318365603 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1849,6 +1849,7 @@ fi
>  AM_CONDITIONAL(HAVE_PLATFORM_X11, echo "$platforms" | grep -q 'x11')
>  AM_CONDITIONAL(HAVE_PLATFORM_WAYLAND, echo "$platforms" | grep -q 'wayland')
>  AM_CONDITIONAL(HAVE_PLATFORM_DRM, echo "$platforms" | grep -q 'drm')
> +AM_CONDITIONAL(HAVE_PLATFORM_DISPLAY, echo "$platforms" | grep -q 'drm')

copy/paste error: s/drm/display/

>  AM_CONDITIONAL(HAVE_PLATFORM_SURFACELESS, echo "$platforms" | grep -q 
> 'surfaceless')
>  AM_CONDITIONAL(HAVE_PLATFORM_ANDROID, echo "$platforms" | grep -q 'android')
>  
> diff --git a/meson.build b/meson.build
> index b39e2f8ab96..aeb7f5e2917 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -239,11 +239,12 @@ with_platform_wayland = false
>  with_platform_x11 = false
>  with_platform_drm = false
>  with_platform_surfaceless = false
> +with_platform_display = false
>  egl_native_platform = ''
>  _platforms = get_option('platforms')
>  if _platforms == 'auto'
>if system_has_kms_drm
> -_platforms = 'x11,wayland,drm,surfaceless'
> +_platforms = 'x11,wayland,drm,surfaceless,display'
>elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
>  _platforms = 'x11,surfaceless'
>else
> @@ -257,6 +258,7 @@ if _platforms != ''
>with_platform_wayland = _split.contains('wayland')
>with_platform_drm = _split.contains('drm')
>with_platform_surfaceless = _split.contains('surfaceless')
> +  with_platform_display = _split.contains('display')
>egl_native_platform = _split[0]
>  endif
>  
> diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
> index 61025968942..061b8144b88 100644
> --- a/src/amd/vulkan/Makefile.am
> +++ b/src/amd/vulkan/Makefile.am
> @@ -76,6 +76,14 @@ VULKAN_LIB_DEPS = \
>   $(DLOPEN_LIBS) \
>   -lm
>  
> +if HAVE_PLATFORM_DISPLAY
> +AM_CPPFLAGS += \
> + -DVK_USE_PLATFORM_DISPLAY_KHR
> +
> +VULKAN_SOURCES += $(VULKAN_WSI_DISPLAY_FILES)
> +
> +endif
> +
>  if HAVE_PLATFORM_X11
>  AM_CPPFLAGS += \
>   $(XCB_DRI3_CFLAGS) \
> diff --git a/src/amd/vulkan/Makefile.sources b/src/amd/vulkan/Makefile.sources
> index a510d88d965..618a6cdaed0 100644
> --- a/src/amd/vulkan/Makefile.sources
> +++ b/src/amd/vulkan/Makefile.sources
> @@ -78,6 +78,9 @@ VULKAN_WSI_WAYLAND_FILES := \
>  VULKAN_WSI_X11_FILES := \
>   radv_wsi_x11.c
>  
> +VULKAN_WSI_DISPLAY_FILES := \
> + radv_wsi_display.c
> +
>  VULKAN_GENERATED_FILES := \
>   radv_entrypoints.c \
>   radv_entrypoints.h \
> diff --git a/src/amd/vulkan/meson.build b/src/amd/vulkan/meson.build
> index 0a7b7c0bf3c..b7bb1075e7d 100644
> --- a/src/amd/vulkan/meson.build
> +++ b/src/amd/vulkan/meson.build
> @@ -112,6 +112,13 @@ if with_platform_wayland
>libradv_files += files('radv_wsi_wayland.c')
>  endif
>  
> +if with_platform_display
> +  radv_flags += [
> +