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

[Jason Ekstrand]

On November 22, 2017 15:12:20 Grazvydas Ignotas <notasas at gmail.com> wrote:

> On Wed, Nov 22, 2017 at 7:54 AM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>> On Tue, Nov 21, 2017 at 1:21 PM, Grazvydas Ignotas <notasas at gmail.com>
>> wrote:
>>>
>>> On Mon, Nov 20, 2017 at 6:08 PM, Jason Ekstrand <jason at jlekstrand.net>
>>> wrote:
>>> > On Sun, Nov 19, 2017 at 5:07 AM, Grazvydas Ignotas <notasas at gmail.com>
>>> > wrote:
>>> >>
>>> >> On Sun, Nov 19, 2017 at 1:51 AM, Jason Ekstrand <jason at jlekstrand.net>
>>> >> 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