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

Grazvydas Ignotas notasas at gmail.com
Wed Nov 22 22:12:18 UTC 2017


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. 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


More information about the mesa-dev mailing list