subject:"\[Mesa\-dev\] \[PATCH 00\/28\] vulkan\/wsi\: Rework WSI to look a lot more like a layer"

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

2017-11-22 Thread Jason Ekstrand

On November 22, 2017 15:12:20 Grazvydas Ignotas  wrote:

On Wed, Nov 22, 2017 at 7:54 AM, Jason Ekstrand  wrote:

On Tue, Nov 21, 2017 at 1:21 PM, Grazvydas Ignotas 
wrote:

On Mon, Nov 20, 2017 at 6:08 PM, Jason Ekstrand 
wrote:
> On Sun, Nov 19, 2017 at 5:07 AM, Grazvydas Ignotas 
> wrote:
>>
>> On Sun, Nov 19, 2017 at 1:51 AM, Jason Ekstrand 
>> wrote:
>> >
>> > I force-pushed the branch again with an added commit: "radv: Move wsi
>> > initialization later in physical_device_init" that fixes the memory
>> > type
>> > issue with radv.  I've tested both radv + radeon and anv + radeon on
>> > my
>> > HSW
>> > + Rx550 and they both work now.  I'm having a bit of trouble actually
>> > getting my system to start up on the Intel card so I'll have to leave
>> > testing radv on Intel for another day.
>>
>> Radv is working now on both displays, however "display on amd + anv"
>> case still acts the same (black window on most, but not all
>> SaschaWillems demos). I'm using xf86-video-amdgpu 1.4.0, 4.14 kernel
>> and xorg-server 1.18.4, if that makes a difference.
>
>
> I'm completely unable to reproduce.  Here's my setup:
>
>  - Fedora 27
>  - X.org 1.19.5
>  - xf86-video-amdgpu 1.3.0
>  - Linux 4.13.12
>  - Intel Haswell
>  - AMD RX550
>
> I've tried with amdgpu, modesetting, and XWayland all running on the AMD
> card and anv works on all three.  I'm a little weirded out by the fact
> that
> my X server is newer but my xf86-video-amdgpu is older.

Well I compiled my own xf86-video-amdgpu. Not sure why.

> Two things I'd like you to try if you can:
>
>  1) Use modesetting.  It may be a bug in your version of amdgpu.

Same results (black window), plus all the tearing all over I usually
get with it. Also tried the distro kernel (4.10).

>  2) Try the attached patch with radv + display on AMD.  It will make
> radv
> use the prime path regardless of the fact that it's displaying on the
> same
> GPU.

Still works fine, albeit a bit slower (as expected I guess).
Maybe something specific to SKL?

I think it may be weirdly enough.  More specifically, I think you're
probably hitting a bug I found today in the Sascha demos that probably only
actually shows up on SKL.  Give this PR a try:

https://github.com/SaschaWillems/Vulkan/pull/400

That helps, thanks.

Cool, glad to see things are working better than that.

But textoverlay and subpasses still show black
screen on amd display and multisampling is dark even on intel. All are
fine on radv on both displays.

Here are some weird ones:
- texture3d works on anv on amd display, but triggers
"vulkan/anv_batch_chain.c:1139: adjust_relocations_from_state_pool:
Assertion `last_pool_center_bo_offset <=
pool->block_pool.center_bo_offset' failed." on intel display.
- multisampling on radv isn't clearing the background on intel
display, but is fine on amd display.

Thanks for the info, I'll look into it on Monday.

--Jason

In other tests with this series, Talos Principle and Serious Sam
Fusion work on anv+amd display, while DOOM is failing with
VK_ERROR_FEATURE_NOT_PRESENT on any display (and does so for many
months now, probably since 5dd96b1156, but I haven't tried looking
what the feature is).

Gražvydas

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

2017-11-22 Thread Grazvydas Ignotas

On Wed, Nov 22, 2017 at 7:54 AM, Jason Ekstrand  wrote:
> On Tue, Nov 21, 2017 at 1:21 PM, Grazvydas Ignotas 
> wrote:
>>
>> On Mon, Nov 20, 2017 at 6:08 PM, Jason Ekstrand 
>> wrote:
>> > On Sun, Nov 19, 2017 at 5:07 AM, Grazvydas Ignotas 
>> > wrote:
>> >>
>> >> On Sun, Nov 19, 2017 at 1:51 AM, Jason Ekstrand 
>> >> wrote:
>> >> >
>> >> > I force-pushed the branch again with an added commit: "radv: Move wsi
>> >> > initialization later in physical_device_init" that fixes the memory
>> >> > type
>> >> > issue with radv.  I've tested both radv + radeon and anv + radeon on
>> >> > my
>> >> > HSW
>> >> > + Rx550 and they both work now.  I'm having a bit of trouble actually
>> >> > getting my system to start up on the Intel card so I'll have to leave
>> >> > testing radv on Intel for another day.
>> >>
>> >> Radv is working now on both displays, however "display on amd + anv"
>> >> case still acts the same (black window on most, but not all
>> >> SaschaWillems demos). I'm using xf86-video-amdgpu 1.4.0, 4.14 kernel
>> >> and xorg-server 1.18.4, if that makes a difference.
>> >
>> >
>> > I'm completely unable to reproduce.  Here's my setup:
>> >
>> >  - Fedora 27
>> >  - X.org 1.19.5
>> >  - xf86-video-amdgpu 1.3.0
>> >  - Linux 4.13.12
>> >  - Intel Haswell
>> >  - AMD RX550
>> >
>> > I've tried with amdgpu, modesetting, and XWayland all running on the AMD
>> > card and anv works on all three.  I'm a little weirded out by the fact
>> > that
>> > my X server is newer but my xf86-video-amdgpu is older.
>>
>> Well I compiled my own xf86-video-amdgpu. Not sure why.
>>
>> > Two things I'd like you to try if you can:
>> >
>> >  1) Use modesetting.  It may be a bug in your version of amdgpu.
>>
>> Same results (black window), plus all the tearing all over I usually
>> get with it. Also tried the distro kernel (4.10).
>>
>> >  2) Try the attached patch with radv + display on AMD.  It will make
>> > radv
>> > use the prime path regardless of the fact that it's displaying on the
>> > same
>> > GPU.
>>
>> Still works fine, albeit a bit slower (as expected I guess).
>> Maybe something specific to SKL?
>
>
> I think it may be weirdly enough.  More specifically, I think you're
> probably hitting a bug I found today in the Sascha demos that probably only
> actually shows up on SKL.  Give this PR a try:
>
> https://github.com/SaschaWillems/Vulkan/pull/400

That helps, thanks. But textoverlay and subpasses still show black
screen on amd display and multisampling is dark even on intel. All are
fine on radv on both displays.

Here are some weird ones:
- texture3d works on anv on amd display, but triggers
"vulkan/anv_batch_chain.c:1139: adjust_relocations_from_state_pool:
Assertion `last_pool_center_bo_offset <=
pool->block_pool.center_bo_offset' failed." on intel display.
- multisampling on radv isn't clearing the background on intel
display, but is fine on amd display.

In other tests with this series, Talos Principle and Serious Sam
Fusion work on anv+amd display, while DOOM is failing with
VK_ERROR_FEATURE_NOT_PRESENT on any display (and does so for many
months now, probably since 5dd96b1156, but I haven't tried looking
what the feature is).

Gražvydas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

2017-11-21 Thread Jason Ekstrand

On Tue, Nov 21, 2017 at 1:21 PM, Grazvydas Ignotas 
wrote:

> On Mon, Nov 20, 2017 at 6:08 PM, Jason Ekstrand 
> wrote:
> > On Sun, Nov 19, 2017 at 5:07 AM, Grazvydas Ignotas 
> > wrote:
> >>
> >> On Sun, Nov 19, 2017 at 1:51 AM, Jason Ekstrand 
> >> wrote:
> >> >
> >> > I force-pushed the branch again with an added commit: "radv: Move wsi
> >> > initialization later in physical_device_init" that fixes the memory
> type
> >> > issue with radv.  I've tested both radv + radeon and anv + radeon on
> my
> >> > HSW
> >> > + Rx550 and they both work now.  I'm having a bit of trouble actually
> >> > getting my system to start up on the Intel card so I'll have to leave
> >> > testing radv on Intel for another day.
> >>
> >> Radv is working now on both displays, however "display on amd + anv"
> >> case still acts the same (black window on most, but not all
> >> SaschaWillems demos). I'm using xf86-video-amdgpu 1.4.0, 4.14 kernel
> >> and xorg-server 1.18.4, if that makes a difference.
> >
> >
> > I'm completely unable to reproduce.  Here's my setup:
> >
> >  - Fedora 27
> >  - X.org 1.19.5
> >  - xf86-video-amdgpu 1.3.0
> >  - Linux 4.13.12
> >  - Intel Haswell
> >  - AMD RX550
> >
> > I've tried with amdgpu, modesetting, and XWayland all running on the AMD
> > card and anv works on all three.  I'm a little weirded out by the fact
> that
> > my X server is newer but my xf86-video-amdgpu is older.
>
> Well I compiled my own xf86-video-amdgpu. Not sure why.
>
> > Two things I'd like you to try if you can:
> >
> >  1) Use modesetting.  It may be a bug in your version of amdgpu.
>
> Same results (black window), plus all the tearing all over I usually
> get with it. Also tried the distro kernel (4.10).
>
> >  2) Try the attached patch with radv + display on AMD.  It will make radv
> > use the prime path regardless of the fact that it's displaying on the
> same
> > GPU.
>
> Still works fine, albeit a bit slower (as expected I guess).
> Maybe something specific to SKL?
>

I think it may be weirdly enough.  More specifically, I think you're
probably hitting a bug I found today in the Sascha demos that probably only
actually shows up on SKL.  Give this PR a try:

https://github.com/SaschaWillems/Vulkan/pull/400

--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

2017-11-21 Thread Grazvydas Ignotas

On Mon, Nov 20, 2017 at 6:08 PM, Jason Ekstrand  wrote:
> On Sun, Nov 19, 2017 at 5:07 AM, Grazvydas Ignotas 
> wrote:
>>
>> On Sun, Nov 19, 2017 at 1:51 AM, Jason Ekstrand 
>> wrote:
>> >
>> > I force-pushed the branch again with an added commit: "radv: Move wsi
>> > initialization later in physical_device_init" that fixes the memory type
>> > issue with radv.  I've tested both radv + radeon and anv + radeon on my
>> > HSW
>> > + Rx550 and they both work now.  I'm having a bit of trouble actually
>> > getting my system to start up on the Intel card so I'll have to leave
>> > testing radv on Intel for another day.
>>
>> Radv is working now on both displays, however "display on amd + anv"
>> case still acts the same (black window on most, but not all
>> SaschaWillems demos). I'm using xf86-video-amdgpu 1.4.0, 4.14 kernel
>> and xorg-server 1.18.4, if that makes a difference.
>
>
> I'm completely unable to reproduce.  Here's my setup:
>
>  - Fedora 27
>  - X.org 1.19.5
>  - xf86-video-amdgpu 1.3.0
>  - Linux 4.13.12
>  - Intel Haswell
>  - AMD RX550
>
> I've tried with amdgpu, modesetting, and XWayland all running on the AMD
> card and anv works on all three.  I'm a little weirded out by the fact that
> my X server is newer but my xf86-video-amdgpu is older.

Well I compiled my own xf86-video-amdgpu. Not sure why.

> Two things I'd like you to try if you can:
>
>  1) Use modesetting.  It may be a bug in your version of amdgpu.

Same results (black window), plus all the tearing all over I usually
get with it. Also tried the distro kernel (4.10).

>  2) Try the attached patch with radv + display on AMD.  It will make radv
> use the prime path regardless of the fact that it's displaying on the same
> GPU.

Still works fine, albeit a bit slower (as expected I guess).
Maybe something specific to SKL?

Gražvydas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

2017-11-20 Thread James Jones


On 11/16/2017 01:28 PM, Jason Ekstrand wrote:

This patch series is the combined brain-child of Dave and myself.  The
objective is to rewrite Vulkan WSI to look as much like a layer as possible
and to reduce the driver <-> WSI interface.  We try very hard to have as
many of the WSI details as possible in common code and to use standard
Vulkan interfaces for everything.  Among other things, this means that
prime support is now implemented in an entirely driver-agnostic way and the
driver doesn't even know it's happening.  As a side-effect anv now has
prime support.

Eventually, someone could pull what's left out into a proper layer and we
could drop WSI support from our drivers entirely.  There are a fiew pieces
of work that would be required to do this:

  1) Write all of the annoying layer bits.  There are some short-cuts that
 we can take because we're not in a layer and those will have to go.

  2) Define a VK_MESA_legacy_swapchain_image extension to replace the hack
 introduced in patch 8.

  3) It looks like modifiers support will land before the official Vulkan
 extensions get finished.  It will have to be ported to the official
 extensions.

  4) Figure out what to do about the fence in AcquireNextImage. In a future
 world of explicit synchronization, we can just import the sync_file
 from X or the Wayland compositor, but with implicit sync like we have
 today, it's a bit harder.  Right now, the helper in wsi_common does
 nothing with it and trusts the caller to handle it.

 The two drivers handle this differently today.  In anv, we do a dummy
 QueueSubmit to trigger the fence while radv triggers it a bit more
 manually.  In both cases, we trigger the fence immediately and trust in
 the GEM's implicit synchronization to sort things out for us.  We can't
 use the anv method as directly with radv because no queue is passed in
 so we don't know what queue to use in the dummy QueueSubmit.  (In ANV,
 we only have the one queue so that isn't a problem.)


I don't have detailed feedback, but I read through the series and this 
is pretty cool.  Glad things are starting to generalize across the 
driver stacks.  I'm optimistic that things have gotten to the point 
where we'll never have to write a separate Wayland WSI for our driver. 
Is it an accurate observation to say there aren't any Vulkan API bits 
missing (other than stuff in the pipeline like modifiers/dma-buf) to 
allow the full-layer solution?  Hopefully we haven't missed anything in 
the external_* extensions at this point.


Thanks,
-James


Dave, I tried to pull patches from your series where practical but, because
we did things in a different order, it frequently wasn't.  If you want to
claim credit for any of these patches, just say so and I'll --reset-author
on them.

The series can be found on freedesktop.org here:

https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/vulkan-wsi-prime


Cc: Dave Airlie 
Cc: Daniel Stone 
Cc: Chad Versace 
Cc: James Jones 

Daniel Stone (1):
   vulkan/wsi: Add a wsi_image structure

Dave Airlie (4):
   vulkan/wsi: use function ptr definitions from the spec.
   radv/wsi: drop allocate memory special case
   radv/wsi: Move the guts of QueuePresent to wsi common
   vulkan/wsi: move swapchain create/destroy to common code

Jason Ekstrand (23):
   vulkan/wsi/x11: Handle the geometry check earlier in create_swapchain
   vulkan/wsi: Add a wsi_device_init function
   vulkan/wsi: Add wsi_swapchain_init/finish functions
   vulkan/wsi: Implement prime in a completely generic way
   anv/image: Add a return value to bind_memory_plane
   vulkan/wsi: Add a mock image creation extension
   anv/image: Implement the wsi "extension"
   radv/image: Implement the wsi "extension"
   vulkan/wsi: Do image creation in common code
   vulkan/wsi: Add a WSI_FROM_HANDLE macro
   vulkan/wsi: Refactor result handling in queue_present
   vulkan/wsi: Only wait on semaphores on the first swapchain
   vulkan/wsi: Set a proper pWaitDstStageMask on the dummy submit
   anv/wsi: Use the common QueuePresent code
   anv/wsi: Enable prime support
   vulkan/wsi: Move get_images into common code
   vulkan/wsi: Move prime blitting into queue_present
   vulkan/wsi: Add a helper for AcquireNextImage
   vulkan/wsi: Move wsi_swapchain to wsi_common_private.h
   vulkan/wsi: Drop the can_handle_different_gpu parameter from
 get_support
   vulkan/wsi: Add wrappers for all of the surface queries
   vulkan/wsi: Drop some unneeded cruft from the API
   vulkan/wsi: Initialize individual WSI interfaces in wsi_device_init

  src/amd/vulkan/radv_device.c|  18 +-
  src/amd/vulkan/radv_image.c |  15 +-
  src/amd/vulkan/radv_private.h   |  10 -
  src/amd/vulkan/radv_wsi.c   | 472 +++---
  src/intel/vulkan/anv_image.c|  71 +++-
  src/intel/vulkan/anv_private.h

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

2017-11-20 Thread Jason Ekstrand

On Sun, Nov 19, 2017 at 5:07 AM, Grazvydas Ignotas 
wrote:

> On Sun, Nov 19, 2017 at 1:51 AM, Jason Ekstrand 
> wrote:
> > On Sat, Nov 18, 2017 at 9:02 AM, Grazvydas Ignotas 
> > wrote:
> >>
> >> On Sat, Nov 18, 2017 at 3:06 AM, Jason Ekstrand 
> >> wrote:
> >> > On Fri, Nov 17, 2017 at 2:18 PM, Grazvydas Ignotas  >
> >> > wrote:
> >> >>
> >> >> I've tested this branch (rx470 + hd530) and it's only partially
> >> >> working:
> >> >> - display on amd, radv: always fails with "offscreen:
> >> >> wsi/wsi_common.c:172: select_memory_type: Assertion `!"No memory type
> >> >> found"' failed."
> >> >> - display on amd, anv: misrenders. For SaschaWillems, only
> >> >> multisampling, subpasses and triangle renders, other demos show black
> >> >> window with only text (fps counter and help) visible
> >> >> - display on intel, radv: same "No memory type found"'
> >> >> - display on intel, anv: seems to be ok
> >> >
> >> >
> >> > Thanks for testing!  I've got a HSW+radeon box at home.  I'll see if I
> >> > can
> >> > get it fixed early next week.  I did find a couple bugs by inspection
> >> > when I
> >> > was working on getting modifiers working today.  I've re-pushed if you
> >> > feel
> >> > like trying again.  Otherwise, I'll see if I can repro on my box.
> >>
> >> Seems to be the same as before. Assertion `!"No memory type found"'
> >> starts hitting at "vulkan/wsi: Do image creation in common code".
> >
> >
> > I force-pushed the branch again with an added commit: "radv: Move wsi
> > initialization later in physical_device_init" that fixes the memory type
> > issue with radv.  I've tested both radv + radeon and anv + radeon on my
> HSW
> > + Rx550 and they both work now.  I'm having a bit of trouble actually
> > getting my system to start up on the Intel card so I'll have to leave
> > testing radv on Intel for another day.
>
> Radv is working now on both displays, however "display on amd + anv"
> case still acts the same (black window on most, but not all
> SaschaWillems demos). I'm using xf86-video-amdgpu 1.4.0, 4.14 kernel
> and xorg-server 1.18.4, if that makes a difference.
>

I'm completely unable to reproduce.  Here's my setup:

 - Fedora 27
 - X.org 1.19.5
 - xf86-video-amdgpu 1.3.0
 - Linux 4.13.12
 - Intel Haswell
 - AMD RX550

I've tried with amdgpu, modesetting, and XWayland all running on the AMD
card and anv works on all three.  I'm a little weirded out by the fact that
my X server is newer but my xf86-video-amdgpu is older.

Two things I'd like you to try if you can:

 1) Use modesetting.  It may be a bug in your version of amdgpu.
 2) Try the attached patch with radv + display on AMD.  It will make radv
use the prime path regardless of the fact that it's displaying on the same
GPU.

Thanks!

--Jason
From dc9d55cfa382e07fa9cb3c0a7469b6ee962678f1 Mon Sep 17 00:00:00 2001
From: Jason Ekstrand 
Date: Mon, 20 Nov 2017 08:04:23 -0800
Subject: [PATCH] HACK: vulkan/wsi/x11: Pretend we're always using prime

---
 src/vulkan/wsi/wsi_common_x11.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_x11.c
index c29e0a2..cc89def 100644
--- a/src/vulkan/wsi/wsi_common_x11.c
+++ b/src/vulkan/wsi/wsi_common_x11.c
@@ -1083,6 +1083,7 @@ x11_surface_create_swapchain(VkIcdSurfaceBase *icd_surface,
chain->threaded = false;
chain->status = VK_SUCCESS;
 
+   chain->base.use_prime_blit = true;
if (!wsi_x11_check_dri3_compatible(conn, local_fd))
chain->base.use_prime_blit = true;
 
-- 
2.5.0.400.gff86faf

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

2017-11-19 Thread Grazvydas Ignotas

On Sun, Nov 19, 2017 at 1:51 AM, Jason Ekstrand  wrote:
> On Sat, Nov 18, 2017 at 9:02 AM, Grazvydas Ignotas 
> wrote:
>>
>> On Sat, Nov 18, 2017 at 3:06 AM, Jason Ekstrand 
>> wrote:
>> > On Fri, Nov 17, 2017 at 2:18 PM, Grazvydas Ignotas 
>> > wrote:
>> >>
>> >> I've tested this branch (rx470 + hd530) and it's only partially
>> >> working:
>> >> - display on amd, radv: always fails with "offscreen:
>> >> wsi/wsi_common.c:172: select_memory_type: Assertion `!"No memory type
>> >> found"' failed."
>> >> - display on amd, anv: misrenders. For SaschaWillems, only
>> >> multisampling, subpasses and triangle renders, other demos show black
>> >> window with only text (fps counter and help) visible
>> >> - display on intel, radv: same "No memory type found"'
>> >> - display on intel, anv: seems to be ok
>> >
>> >
>> > Thanks for testing!  I've got a HSW+radeon box at home.  I'll see if I
>> > can
>> > get it fixed early next week.  I did find a couple bugs by inspection
>> > when I
>> > was working on getting modifiers working today.  I've re-pushed if you
>> > feel
>> > like trying again.  Otherwise, I'll see if I can repro on my box.
>>
>> Seems to be the same as before. Assertion `!"No memory type found"'
>> starts hitting at "vulkan/wsi: Do image creation in common code".
>
>
> I force-pushed the branch again with an added commit: "radv: Move wsi
> initialization later in physical_device_init" that fixes the memory type
> issue with radv.  I've tested both radv + radeon and anv + radeon on my HSW
> + Rx550 and they both work now.  I'm having a bit of trouble actually
> getting my system to start up on the Intel card so I'll have to leave
> testing radv on Intel for another day.

Radv is working now on both displays, however "display on amd + anv"
case still acts the same (black window on most, but not all
SaschaWillems demos). I'm using xf86-video-amdgpu 1.4.0, 4.14 kernel
and xorg-server 1.18.4, if that makes a difference.

Gražvydas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

2017-11-18 Thread Jason Ekstrand

On Sat, Nov 18, 2017 at 9:02 AM, Grazvydas Ignotas 
wrote:

> On Sat, Nov 18, 2017 at 3:06 AM, Jason Ekstrand 
> wrote:
> > On Fri, Nov 17, 2017 at 2:18 PM, Grazvydas Ignotas 
> > wrote:
> >>
> >> I've tested this branch (rx470 + hd530) and it's only partially working:
> >> - display on amd, radv: always fails with "offscreen:
> >> wsi/wsi_common.c:172: select_memory_type: Assertion `!"No memory type
> >> found"' failed."
> >> - display on amd, anv: misrenders. For SaschaWillems, only
> >> multisampling, subpasses and triangle renders, other demos show black
> >> window with only text (fps counter and help) visible
> >> - display on intel, radv: same "No memory type found"'
> >> - display on intel, anv: seems to be ok
> >
> >
> > Thanks for testing!  I've got a HSW+radeon box at home.  I'll see if I
> can
> > get it fixed early next week.  I did find a couple bugs by inspection
> when I
> > was working on getting modifiers working today.  I've re-pushed if you
> feel
> > like trying again.  Otherwise, I'll see if I can repro on my box.
>
> Seems to be the same as before. Assertion `!"No memory type found"'
> starts hitting at "vulkan/wsi: Do image creation in common code".
>

I force-pushed the branch again with an added commit: "radv: Move wsi
initialization later in physical_device_init" that fixes the memory type
issue with radv.  I've tested both radv + radeon and anv + radeon on my HSW
+ Rx550 and they both work now.  I'm having a bit of trouble actually
getting my system to start up on the Intel card so I'll have to leave
testing radv on Intel for another day.

--Jason


> Gražvydas
>
> >
> > --Jason
> >
> >>
> >> Gražvydas
> >>
> >> On Fri, Nov 17, 2017 at 4:44 AM, Jason Ekstrand 
> >> wrote:
> >> > I just force-pushed my branch with some changes as per Dave to more
> >> > explicitly enable implicit sync when allocating memory objects.
> >> >
> >> > On Thu, Nov 16, 2017 at 1:28 PM, Jason Ekstrand  >
> >> > wrote:
> >> >>
> >> >> This patch series is the combined brain-child of Dave and myself.
> The
> >> >> objective is to rewrite Vulkan WSI to look as much like a layer as
> >> >> possible
> >> >> and to reduce the driver <-> WSI interface.  We try very hard to have
> >> >> as
> >> >> many of the WSI details as possible in common code and to use
> standard
> >> >> Vulkan interfaces for everything.  Among other things, this means
> that
> >> >> prime support is now implemented in an entirely driver-agnostic way
> and
> >> >> the
> >> >> driver doesn't even know it's happening.  As a side-effect anv now
> has
> >> >> prime support.
> >> >>
> >> >> Eventually, someone could pull what's left out into a proper layer
> and
> >> >> we
> >> >> could drop WSI support from our drivers entirely.  There are a fiew
> >> >> pieces
> >> >> of work that would be required to do this:
> >> >>
> >> >>  1) Write all of the annoying layer bits.  There are some short-cuts
> >> >> that
> >> >> we can take because we're not in a layer and those will have to
> go.
> >> >>
> >> >>  2) Define a VK_MESA_legacy_swapchain_image extension to replace the
> >> >> hack
> >> >> introduced in patch 8.
> >> >>
> >> >>  3) It looks like modifiers support will land before the official
> >> >> Vulkan
> >> >> extensions get finished.  It will have to be ported to the
> official
> >> >> extensions.
> >> >>
> >> >>  4) Figure out what to do about the fence in AcquireNextImage. In a
> >> >> future
> >> >> world of explicit synchronization, we can just import the
> sync_file
> >> >> from X or the Wayland compositor, but with implicit sync like we
> >> >> have
> >> >> today, it's a bit harder.  Right now, the helper in wsi_common
> does
> >> >> nothing with it and trusts the caller to handle it.
> >> >>
> >> >> The two drivers handle this differently today.  In anv, we do a
> >> >> dummy
> >> >> QueueSubmit to trigger the fence while radv triggers it a bit
> more
> >> >> manually.  In both cases, we trigger the fence immediately and
> >> >> trust
> >> >> in
> >> >> the GEM's implicit synchronization to sort things out for us.  We
> >> >> can't
> >> >> use the anv method as directly with radv because no queue is
> passed
> >> >> in
> >> >> so we don't know what queue to use in the dummy QueueSubmit.  (In
> >> >> ANV,
> >> >> we only have the one queue so that isn't a problem.)
> >> >>
> >> >>
> >> >> Dave, I tried to pull patches from your series where practical but,
> >> >> because
> >> >> we did things in a different order, it frequently wasn't.  If you
> want
> >> >> to
> >> >> claim credit for any of these patches, just say so and I'll
> >> >> --reset-author
> >> >> on them.
> >> >>
> >> >> The series can be found on freedesktop.org here:
> >> >>
> >> >>
> >> >> https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/vulk
> an-wsi-prime
> >> >>
> >> >>
> >> >> Cc: Dave Airlie

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

2017-11-18 Thread Grazvydas Ignotas

On Sat, Nov 18, 2017 at 3:06 AM, Jason Ekstrand  wrote:
> On Fri, Nov 17, 2017 at 2:18 PM, Grazvydas Ignotas 
> wrote:
>>
>> I've tested this branch (rx470 + hd530) and it's only partially working:
>> - display on amd, radv: always fails with "offscreen:
>> wsi/wsi_common.c:172: select_memory_type: Assertion `!"No memory type
>> found"' failed."
>> - display on amd, anv: misrenders. For SaschaWillems, only
>> multisampling, subpasses and triangle renders, other demos show black
>> window with only text (fps counter and help) visible
>> - display on intel, radv: same "No memory type found"'
>> - display on intel, anv: seems to be ok
>
>
> Thanks for testing!  I've got a HSW+radeon box at home.  I'll see if I can
> get it fixed early next week.  I did find a couple bugs by inspection when I
> was working on getting modifiers working today.  I've re-pushed if you feel
> like trying again.  Otherwise, I'll see if I can repro on my box.

Seems to be the same as before. Assertion `!"No memory type found"'
starts hitting at "vulkan/wsi: Do image creation in common code".

Gražvydas

>
> --Jason
>
>>
>> Gražvydas
>>
>> On Fri, Nov 17, 2017 at 4:44 AM, Jason Ekstrand 
>> wrote:
>> > I just force-pushed my branch with some changes as per Dave to more
>> > explicitly enable implicit sync when allocating memory objects.
>> >
>> > On Thu, Nov 16, 2017 at 1:28 PM, Jason Ekstrand 
>> > wrote:
>> >>
>> >> This patch series is the combined brain-child of Dave and myself.  The
>> >> objective is to rewrite Vulkan WSI to look as much like a layer as
>> >> possible
>> >> and to reduce the driver <-> WSI interface.  We try very hard to have
>> >> as
>> >> many of the WSI details as possible in common code and to use standard
>> >> Vulkan interfaces for everything.  Among other things, this means that
>> >> prime support is now implemented in an entirely driver-agnostic way and
>> >> the
>> >> driver doesn't even know it's happening.  As a side-effect anv now has
>> >> prime support.
>> >>
>> >> Eventually, someone could pull what's left out into a proper layer and
>> >> we
>> >> could drop WSI support from our drivers entirely.  There are a fiew
>> >> pieces
>> >> of work that would be required to do this:
>> >>
>> >>  1) Write all of the annoying layer bits.  There are some short-cuts
>> >> that
>> >> we can take because we're not in a layer and those will have to go.
>> >>
>> >>  2) Define a VK_MESA_legacy_swapchain_image extension to replace the
>> >> hack
>> >> introduced in patch 8.
>> >>
>> >>  3) It looks like modifiers support will land before the official
>> >> Vulkan
>> >> extensions get finished.  It will have to be ported to the official
>> >> extensions.
>> >>
>> >>  4) Figure out what to do about the fence in AcquireNextImage. In a
>> >> future
>> >> world of explicit synchronization, we can just import the sync_file
>> >> from X or the Wayland compositor, but with implicit sync like we
>> >> have
>> >> today, it's a bit harder.  Right now, the helper in wsi_common does
>> >> nothing with it and trusts the caller to handle it.
>> >>
>> >> The two drivers handle this differently today.  In anv, we do a
>> >> dummy
>> >> QueueSubmit to trigger the fence while radv triggers it a bit more
>> >> manually.  In both cases, we trigger the fence immediately and
>> >> trust
>> >> in
>> >> the GEM's implicit synchronization to sort things out for us.  We
>> >> can't
>> >> use the anv method as directly with radv because no queue is passed
>> >> in
>> >> so we don't know what queue to use in the dummy QueueSubmit.  (In
>> >> ANV,
>> >> we only have the one queue so that isn't a problem.)
>> >>
>> >>
>> >> Dave, I tried to pull patches from your series where practical but,
>> >> because
>> >> we did things in a different order, it frequently wasn't.  If you want
>> >> to
>> >> claim credit for any of these patches, just say so and I'll
>> >> --reset-author
>> >> on them.
>> >>
>> >> The series can be found on freedesktop.org here:
>> >>
>> >>
>> >> https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/vulkan-wsi-prime
>> >>
>> >>
>> >> Cc: Dave Airlie 
>> >> Cc: Daniel Stone 
>> >> Cc: Chad Versace 
>> >> Cc: James Jones 
>> >>
>> >> Daniel Stone (1):
>> >>   vulkan/wsi: Add a wsi_image structure
>> >>
>> >> Dave Airlie (4):
>> >>   vulkan/wsi: use function ptr definitions from the spec.
>> >>   radv/wsi: drop allocate memory special case
>> >>   radv/wsi: Move the guts of QueuePresent to wsi common
>> >>   vulkan/wsi: move swapchain create/destroy to common code
>> >>
>> >> Jason Ekstrand (23):
>> >>   vulkan/wsi/x11: Handle the geometry check earlier in create_swapchain
>> >>   vulkan/wsi: Add a wsi_device_init function
>> >>   vulkan/wsi: Add wsi_swapchain_init/finish functions
>> >>

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

2017-11-17 Thread Jason Ekstrand

On Fri, Nov 17, 2017 at 2:18 PM, Grazvydas Ignotas 
wrote:

> I've tested this branch (rx470 + hd530) and it's only partially working:
> - display on amd, radv: always fails with "offscreen:
> wsi/wsi_common.c:172: select_memory_type: Assertion `!"No memory type
> found"' failed."
> - display on amd, anv: misrenders. For SaschaWillems, only
> multisampling, subpasses and triangle renders, other demos show black
> window with only text (fps counter and help) visible
> - display on intel, radv: same "No memory type found"'
> - display on intel, anv: seems to be ok
>

Thanks for testing!  I've got a HSW+radeon box at home.  I'll see if I can
get it fixed early next week.  I did find a couple bugs by inspection when
I was working on getting modifiers working today.  I've re-pushed if you
feel like trying again.  Otherwise, I'll see if I can repro on my box.

--Jason


> Gražvydas
>
> On Fri, Nov 17, 2017 at 4:44 AM, Jason Ekstrand 
> wrote:
> > I just force-pushed my branch with some changes as per Dave to more
> > explicitly enable implicit sync when allocating memory objects.
> >
> > On Thu, Nov 16, 2017 at 1:28 PM, Jason Ekstrand 
> > wrote:
> >>
> >> This patch series is the combined brain-child of Dave and myself.  The
> >> objective is to rewrite Vulkan WSI to look as much like a layer as
> >> possible
> >> and to reduce the driver <-> WSI interface.  We try very hard to have as
> >> many of the WSI details as possible in common code and to use standard
> >> Vulkan interfaces for everything.  Among other things, this means that
> >> prime support is now implemented in an entirely driver-agnostic way and
> >> the
> >> driver doesn't even know it's happening.  As a side-effect anv now has
> >> prime support.
> >>
> >> Eventually, someone could pull what's left out into a proper layer and
> we
> >> could drop WSI support from our drivers entirely.  There are a fiew
> pieces
> >> of work that would be required to do this:
> >>
> >>  1) Write all of the annoying layer bits.  There are some short-cuts
> that
> >> we can take because we're not in a layer and those will have to go.
> >>
> >>  2) Define a VK_MESA_legacy_swapchain_image extension to replace the
> hack
> >> introduced in patch 8.
> >>
> >>  3) It looks like modifiers support will land before the official Vulkan
> >> extensions get finished.  It will have to be ported to the official
> >> extensions.
> >>
> >>  4) Figure out what to do about the fence in AcquireNextImage. In a
> future
> >> world of explicit synchronization, we can just import the sync_file
> >> from X or the Wayland compositor, but with implicit sync like we
> have
> >> today, it's a bit harder.  Right now, the helper in wsi_common does
> >> nothing with it and trusts the caller to handle it.
> >>
> >> The two drivers handle this differently today.  In anv, we do a
> dummy
> >> QueueSubmit to trigger the fence while radv triggers it a bit more
> >> manually.  In both cases, we trigger the fence immediately and trust
> >> in
> >> the GEM's implicit synchronization to sort things out for us.  We
> >> can't
> >> use the anv method as directly with radv because no queue is passed
> in
> >> so we don't know what queue to use in the dummy QueueSubmit.  (In
> ANV,
> >> we only have the one queue so that isn't a problem.)
> >>
> >>
> >> Dave, I tried to pull patches from your series where practical but,
> >> because
> >> we did things in a different order, it frequently wasn't.  If you want
> to
> >> claim credit for any of these patches, just say so and I'll
> --reset-author
> >> on them.
> >>
> >> The series can be found on freedesktop.org here:
> >>
> >> https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/
> vulkan-wsi-prime
> >>
> >>
> >> Cc: Dave Airlie 
> >> Cc: Daniel Stone 
> >> Cc: Chad Versace 
> >> Cc: James Jones 
> >>
> >> Daniel Stone (1):
> >>   vulkan/wsi: Add a wsi_image structure
> >>
> >> Dave Airlie (4):
> >>   vulkan/wsi: use function ptr definitions from the spec.
> >>   radv/wsi: drop allocate memory special case
> >>   radv/wsi: Move the guts of QueuePresent to wsi common
> >>   vulkan/wsi: move swapchain create/destroy to common code
> >>
> >> Jason Ekstrand (23):
> >>   vulkan/wsi/x11: Handle the geometry check earlier in create_swapchain
> >>   vulkan/wsi: Add a wsi_device_init function
> >>   vulkan/wsi: Add wsi_swapchain_init/finish functions
> >>   vulkan/wsi: Implement prime in a completely generic way
> >>   anv/image: Add a return value to bind_memory_plane
> >>   vulkan/wsi: Add a mock image creation extension
> >>   anv/image: Implement the wsi "extension"
> >>   radv/image: Implement the wsi "extension"
> >>   vulkan/wsi: Do image creation in common code
> >>   vulkan/wsi: Add a WSI_FROM_HANDLE macro
> >>   vulkan/wsi: Refactor result

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

2017-11-17 Thread Grazvydas Ignotas

I've tested this branch (rx470 + hd530) and it's only partially working:
- display on amd, radv: always fails with "offscreen:
wsi/wsi_common.c:172: select_memory_type: Assertion `!"No memory type
found"' failed."
- display on amd, anv: misrenders. For SaschaWillems, only
multisampling, subpasses and triangle renders, other demos show black
window with only text (fps counter and help) visible
- display on intel, radv: same "No memory type found"'
- display on intel, anv: seems to be ok

Gražvydas

On Fri, Nov 17, 2017 at 4:44 AM, Jason Ekstrand  wrote:
> I just force-pushed my branch with some changes as per Dave to more
> explicitly enable implicit sync when allocating memory objects.
>
> On Thu, Nov 16, 2017 at 1:28 PM, Jason Ekstrand 
> wrote:
>>
>> This patch series is the combined brain-child of Dave and myself.  The
>> objective is to rewrite Vulkan WSI to look as much like a layer as
>> possible
>> and to reduce the driver <-> WSI interface.  We try very hard to have as
>> many of the WSI details as possible in common code and to use standard
>> Vulkan interfaces for everything.  Among other things, this means that
>> prime support is now implemented in an entirely driver-agnostic way and
>> the
>> driver doesn't even know it's happening.  As a side-effect anv now has
>> prime support.
>>
>> Eventually, someone could pull what's left out into a proper layer and we
>> could drop WSI support from our drivers entirely.  There are a fiew pieces
>> of work that would be required to do this:
>>
>>  1) Write all of the annoying layer bits.  There are some short-cuts that
>> we can take because we're not in a layer and those will have to go.
>>
>>  2) Define a VK_MESA_legacy_swapchain_image extension to replace the hack
>> introduced in patch 8.
>>
>>  3) It looks like modifiers support will land before the official Vulkan
>> extensions get finished.  It will have to be ported to the official
>> extensions.
>>
>>  4) Figure out what to do about the fence in AcquireNextImage. In a future
>> world of explicit synchronization, we can just import the sync_file
>> from X or the Wayland compositor, but with implicit sync like we have
>> today, it's a bit harder.  Right now, the helper in wsi_common does
>> nothing with it and trusts the caller to handle it.
>>
>> The two drivers handle this differently today.  In anv, we do a dummy
>> QueueSubmit to trigger the fence while radv triggers it a bit more
>> manually.  In both cases, we trigger the fence immediately and trust
>> in
>> the GEM's implicit synchronization to sort things out for us.  We
>> can't
>> use the anv method as directly with radv because no queue is passed in
>> so we don't know what queue to use in the dummy QueueSubmit.  (In ANV,
>> we only have the one queue so that isn't a problem.)
>>
>>
>> Dave, I tried to pull patches from your series where practical but,
>> because
>> we did things in a different order, it frequently wasn't.  If you want to
>> claim credit for any of these patches, just say so and I'll --reset-author
>> on them.
>>
>> The series can be found on freedesktop.org here:
>>
>> https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/vulkan-wsi-prime
>>
>>
>> Cc: Dave Airlie 
>> Cc: Daniel Stone 
>> Cc: Chad Versace 
>> Cc: James Jones 
>>
>> Daniel Stone (1):
>>   vulkan/wsi: Add a wsi_image structure
>>
>> Dave Airlie (4):
>>   vulkan/wsi: use function ptr definitions from the spec.
>>   radv/wsi: drop allocate memory special case
>>   radv/wsi: Move the guts of QueuePresent to wsi common
>>   vulkan/wsi: move swapchain create/destroy to common code
>>
>> Jason Ekstrand (23):
>>   vulkan/wsi/x11: Handle the geometry check earlier in create_swapchain
>>   vulkan/wsi: Add a wsi_device_init function
>>   vulkan/wsi: Add wsi_swapchain_init/finish functions
>>   vulkan/wsi: Implement prime in a completely generic way
>>   anv/image: Add a return value to bind_memory_plane
>>   vulkan/wsi: Add a mock image creation extension
>>   anv/image: Implement the wsi "extension"
>>   radv/image: Implement the wsi "extension"
>>   vulkan/wsi: Do image creation in common code
>>   vulkan/wsi: Add a WSI_FROM_HANDLE macro
>>   vulkan/wsi: Refactor result handling in queue_present
>>   vulkan/wsi: Only wait on semaphores on the first swapchain
>>   vulkan/wsi: Set a proper pWaitDstStageMask on the dummy submit
>>   anv/wsi: Use the common QueuePresent code
>>   anv/wsi: Enable prime support
>>   vulkan/wsi: Move get_images into common code
>>   vulkan/wsi: Move prime blitting into queue_present
>>   vulkan/wsi: Add a helper for AcquireNextImage
>>   vulkan/wsi: Move wsi_swapchain to wsi_common_private.h
>>   vulkan/wsi: Drop the can_handle_different_gpu parameter from
>> get_support
>>   vulkan/wsi: Add wrappers for all of the surface queries
>>

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

2017-11-16 Thread Jason Ekstrand

I just force-pushed my branch with some changes as per Dave to more
explicitly enable implicit sync when allocating memory objects.

On Thu, Nov 16, 2017 at 1:28 PM, Jason Ekstrand 
wrote:

> This patch series is the combined brain-child of Dave and myself.  The
> objective is to rewrite Vulkan WSI to look as much like a layer as possible
> and to reduce the driver <-> WSI interface.  We try very hard to have as
> many of the WSI details as possible in common code and to use standard
> Vulkan interfaces for everything.  Among other things, this means that
> prime support is now implemented in an entirely driver-agnostic way and the
> driver doesn't even know it's happening.  As a side-effect anv now has
> prime support.
>
> Eventually, someone could pull what's left out into a proper layer and we
> could drop WSI support from our drivers entirely.  There are a fiew pieces
> of work that would be required to do this:
>
>  1) Write all of the annoying layer bits.  There are some short-cuts that
> we can take because we're not in a layer and those will have to go.
>
>  2) Define a VK_MESA_legacy_swapchain_image extension to replace the hack
> introduced in patch 8.
>
>  3) It looks like modifiers support will land before the official Vulkan
> extensions get finished.  It will have to be ported to the official
> extensions.
>
>  4) Figure out what to do about the fence in AcquireNextImage. In a future
> world of explicit synchronization, we can just import the sync_file
> from X or the Wayland compositor, but with implicit sync like we have
> today, it's a bit harder.  Right now, the helper in wsi_common does
> nothing with it and trusts the caller to handle it.
>
> The two drivers handle this differently today.  In anv, we do a dummy
> QueueSubmit to trigger the fence while radv triggers it a bit more
> manually.  In both cases, we trigger the fence immediately and trust in
> the GEM's implicit synchronization to sort things out for us.  We can't
> use the anv method as directly with radv because no queue is passed in
> so we don't know what queue to use in the dummy QueueSubmit.  (In ANV,
> we only have the one queue so that isn't a problem.)
>
>
> Dave, I tried to pull patches from your series where practical but, because
> we did things in a different order, it frequently wasn't.  If you want to
> claim credit for any of these patches, just say so and I'll --reset-author
> on them.
>
> The series can be found on freedesktop.org here:
>
> https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/vulkan-wsi-prime
>
>
> Cc: Dave Airlie 
> Cc: Daniel Stone 
> Cc: Chad Versace 
> Cc: James Jones 
>
> Daniel Stone (1):
>   vulkan/wsi: Add a wsi_image structure
>
> Dave Airlie (4):
>   vulkan/wsi: use function ptr definitions from the spec.
>   radv/wsi: drop allocate memory special case
>   radv/wsi: Move the guts of QueuePresent to wsi common
>   vulkan/wsi: move swapchain create/destroy to common code
>
> Jason Ekstrand (23):
>   vulkan/wsi/x11: Handle the geometry check earlier in create_swapchain
>   vulkan/wsi: Add a wsi_device_init function
>   vulkan/wsi: Add wsi_swapchain_init/finish functions
>   vulkan/wsi: Implement prime in a completely generic way
>   anv/image: Add a return value to bind_memory_plane
>   vulkan/wsi: Add a mock image creation extension
>   anv/image: Implement the wsi "extension"
>   radv/image: Implement the wsi "extension"
>   vulkan/wsi: Do image creation in common code
>   vulkan/wsi: Add a WSI_FROM_HANDLE macro
>   vulkan/wsi: Refactor result handling in queue_present
>   vulkan/wsi: Only wait on semaphores on the first swapchain
>   vulkan/wsi: Set a proper pWaitDstStageMask on the dummy submit
>   anv/wsi: Use the common QueuePresent code
>   anv/wsi: Enable prime support
>   vulkan/wsi: Move get_images into common code
>   vulkan/wsi: Move prime blitting into queue_present
>   vulkan/wsi: Add a helper for AcquireNextImage
>   vulkan/wsi: Move wsi_swapchain to wsi_common_private.h
>   vulkan/wsi: Drop the can_handle_different_gpu parameter from
> get_support
>   vulkan/wsi: Add wrappers for all of the surface queries
>   vulkan/wsi: Drop some unneeded cruft from the API
>   vulkan/wsi: Initialize individual WSI interfaces in wsi_device_init
>
>  src/amd/vulkan/radv_device.c|  18 +-
>  src/amd/vulkan/radv_image.c |  15 +-
>  src/amd/vulkan/radv_private.h   |  10 -
>  src/amd/vulkan/radv_wsi.c   | 472 +++---
>  src/intel/vulkan/anv_image.c|  71 +++-
>  src/intel/vulkan/anv_private.h  |   2 +
>  src/intel/vulkan/anv_wsi.c  | 347 +++-
>  src/vulkan/Makefile.sources |   2 +
>  src/vulkan/wsi/meson.build  |   2 +
>  src/vulkan/wsi/wsi_common.c | 763 ++
> ++
>

[Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

2017-11-16 Thread Jason Ekstrand

This patch series is the combined brain-child of Dave and myself.  The
objective is to rewrite Vulkan WSI to look as much like a layer as possible
and to reduce the driver <-> WSI interface.  We try very hard to have as
many of the WSI details as possible in common code and to use standard
Vulkan interfaces for everything.  Among other things, this means that
prime support is now implemented in an entirely driver-agnostic way and the
driver doesn't even know it's happening.  As a side-effect anv now has
prime support.

Eventually, someone could pull what's left out into a proper layer and we
could drop WSI support from our drivers entirely.  There are a fiew pieces
of work that would be required to do this:

 1) Write all of the annoying layer bits.  There are some short-cuts that
we can take because we're not in a layer and those will have to go.

 2) Define a VK_MESA_legacy_swapchain_image extension to replace the hack
introduced in patch 8.

 3) It looks like modifiers support will land before the official Vulkan
extensions get finished.  It will have to be ported to the official
extensions.

 4) Figure out what to do about the fence in AcquireNextImage. In a future
world of explicit synchronization, we can just import the sync_file
from X or the Wayland compositor, but with implicit sync like we have
today, it's a bit harder.  Right now, the helper in wsi_common does
nothing with it and trusts the caller to handle it.

The two drivers handle this differently today.  In anv, we do a dummy
QueueSubmit to trigger the fence while radv triggers it a bit more
manually.  In both cases, we trigger the fence immediately and trust in
the GEM's implicit synchronization to sort things out for us.  We can't
use the anv method as directly with radv because no queue is passed in
so we don't know what queue to use in the dummy QueueSubmit.  (In ANV,
we only have the one queue so that isn't a problem.)


Dave, I tried to pull patches from your series where practical but, because
we did things in a different order, it frequently wasn't.  If you want to
claim credit for any of these patches, just say so and I'll --reset-author
on them.

The series can be found on freedesktop.org here:

https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/vulkan-wsi-prime


Cc: Dave Airlie 
Cc: Daniel Stone 
Cc: Chad Versace 
Cc: James Jones 

Daniel Stone (1):
  vulkan/wsi: Add a wsi_image structure

Dave Airlie (4):
  vulkan/wsi: use function ptr definitions from the spec.
  radv/wsi: drop allocate memory special case
  radv/wsi: Move the guts of QueuePresent to wsi common
  vulkan/wsi: move swapchain create/destroy to common code

Jason Ekstrand (23):
  vulkan/wsi/x11: Handle the geometry check earlier in create_swapchain
  vulkan/wsi: Add a wsi_device_init function
  vulkan/wsi: Add wsi_swapchain_init/finish functions
  vulkan/wsi: Implement prime in a completely generic way
  anv/image: Add a return value to bind_memory_plane
  vulkan/wsi: Add a mock image creation extension
  anv/image: Implement the wsi "extension"
  radv/image: Implement the wsi "extension"
  vulkan/wsi: Do image creation in common code
  vulkan/wsi: Add a WSI_FROM_HANDLE macro
  vulkan/wsi: Refactor result handling in queue_present
  vulkan/wsi: Only wait on semaphores on the first swapchain
  vulkan/wsi: Set a proper pWaitDstStageMask on the dummy submit
  anv/wsi: Use the common QueuePresent code
  anv/wsi: Enable prime support
  vulkan/wsi: Move get_images into common code
  vulkan/wsi: Move prime blitting into queue_present
  vulkan/wsi: Add a helper for AcquireNextImage
  vulkan/wsi: Move wsi_swapchain to wsi_common_private.h
  vulkan/wsi: Drop the can_handle_different_gpu parameter from
get_support
  vulkan/wsi: Add wrappers for all of the surface queries
  vulkan/wsi: Drop some unneeded cruft from the API
  vulkan/wsi: Initialize individual WSI interfaces in wsi_device_init

 src/amd/vulkan/radv_device.c|  18 +-
 src/amd/vulkan/radv_image.c |  15 +-
 src/amd/vulkan/radv_private.h   |  10 -
 src/amd/vulkan/radv_wsi.c   | 472 +++---
 src/intel/vulkan/anv_image.c|  71 +++-
 src/intel/vulkan/anv_private.h  |   2 +
 src/intel/vulkan/anv_wsi.c  | 347 +++-
 src/vulkan/Makefile.sources |   2 +
 src/vulkan/wsi/meson.build  |   2 +
 src/vulkan/wsi/wsi_common.c | 763 
 src/vulkan/wsi/wsi_common.h | 223 ++-
 src/vulkan/wsi/wsi_common_private.h | 157 
 src/vulkan/wsi/wsi_common_wayland.c |  90 ++---
 src/vulkan/wsi/wsi_common_x11.c | 150 ++-
 14 files changed, 1310 insertions(+), 1012 deletions(-)
 create mode 100644 src/vulkan/wsi/wsi_common.c
 create mode 100644 src/vulkan/wsi/wsi_common_private.h

-- 
2.5.0.400.gff86faf

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

Re: [Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

[Mesa-dev] [PATCH 00/28] vulkan/wsi: Rework WSI to look a lot more like a layer

13 matches

Site Navigation

Mail list logo

Footer information