Bug 256793

Summary: x11-wm/sway: WLR_RENDERER=vulkan is broken
Product: Ports & Packages Reporter: Evgeniy Khramtsov <evgeniy>
Component: Individual Port(s)Assignee: Jan Beich <jbeich>
Status: Closed FIXED    
Severity: Affects Only Me CC: evgeniy
Priority: --- Flags: jbeich: maintainer-feedback+
Version: Latest   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
stdout_and_stderr
none
sway -d log when trying to start firefox none

Description Evgeniy Khramtsov 2021-06-23 19:12:53 UTC
$ WLR_RENDERER=vulkan
[wlr] [render/vulkan/vulkan.c:206] Could not create instance: ERROR_LAYER_NOT_PRESENT (-6)
[wlr] [render/vulkan/renderer.c:15251] creating vulkan instance for renderer failed
[wlr] [backend/drm/renderer.c:351] Failed to create renderer
[wlr] [backend/backend.c:2301] Failed to create DRM backend

ports tree: https://codeberg.org/ei/ports/commits/branch/ei

QTJ2 UHD 630 PCI ID 0x3E9B
drm-current-kmod
gl=libglvnd,mesa-devel

graphics/mesa-devel $ make -V SELECTED_OPTIONS
LIBUNWIND LTO VKLAYERS WAYLAND ZSTD anv iris

x11-toolkits/wlroots $ make -V SELECTED_OPTIONS
OPENGL VULKAN

x11-wm/sway $ make -V SELECTED_OPTIONS
BASU PIXBUF

sway started via DRM backend and seatd.

benchmarks/vkmark runs fine, I don't know anything about Vulkan and/or what uses VK layers, also I don't play any games.

If you have any idea how to help to debug this, let me know.
Comment 1 commit-hook freebsd_committer 2021-06-23 19:59:40 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=507dbffa521a9ca9e5a2baacc81262b9bb9da13a

commit 507dbffa521a9ca9e5a2baacc81262b9bb9da13a
Author:     Jan Beich <jbeich@FreeBSD.org>
AuthorDate: 2021-06-23 19:45:54 +0000
Commit:     Jan Beich <jbeich@FreeBSD.org>
CommitDate: 2021-06-23 19:58:54 +0000

    x11-toolkits/wlroots: document Vulkan runtime requirements

    $ pkg install sway

    $ WLR_RENDERER=vulkan sway
    00:00:00.051 [wlr] [render/vulkan/vulkan.c:206] Could not create instance: ERROR_LAYER_NOT_PRESENT (-6)
    00:00:00.051 [wlr] [render/vulkan/renderer.c:1525] creating vulkan instance for renderer failed
    00:00:00.051 [wlr] [backend/backend.c:84] Failed to create backend renderer
    00:00:00.052 [wlr] [render/vulkan/vulkan.c:206] Could not create instance: ERROR_LAYER_NOT_PRESENT (-6)
    00:00:00.052 [wlr] [render/vulkan/renderer.c:1525] creating vulkan instance for renderer failed
    00:00:00.052 [wlr] [backend/backend.c:84] Failed to create backend renderer
    00:00:00.052 [sway/server.c:53] Unable to create backend

    $ pkg install vulkan-validation-layers

    $ WLR_RENDERER=vulkan sway
    00:00:00.063 [wlr] [render/vulkan/vulkan.c:483] vulkan: required device extension VK_EXT_queue_family_foreign not found
    00:00:00.063 [wlr] [render/vulkan/renderer.c:1545] Failed to create vulkan device
    00:00:00.066 [wlr] [backend/backend.c:84] Failed to create backend renderer
    00:00:00.115 [wlr] [render/vulkan/vulkan.c:483] vulkan: required device extension VK_EXT_queue_family_foreign not found
    00:00:00.115 [wlr] [render/vulkan/renderer.c:1545] Failed to create vulkan device
    00:00:00.118 [wlr] [backend/backend.c:84] Failed to create backend renderer
    00:00:00.119 [sway/server.c:53] Unable to create backend

    $ pkg install mesa-devel

    $ WLR_RENDERER=vulkan sway -d
    [...]
    00:00:00.153 [wlr] [render/vulkan/texture.c:217] vulkan_texture_from_pixels: AR24, 10x16
    00:00:00.153 [wlr] [render/vulkan/renderer.c:297] Created new vk staging buffer of size 1048576
    00:00:00.154 [wlr] [render/swapchain.c:105] Allocating new swapchain buffer
    00:00:00.154 [wlr] [render/gbm_allocator.c:130] Allocated 10x16 GBM buffer (format 0x34325241, modifier 0x100000000000002)
    00:00:00.154 [wlr] [render/vulkan/renderer.c:433] vulkan create_render_buffer: AR24, 10x16
    00:00:00.154 [wlr] [render/vulkan/texture.c:354] vulkan_import_dmabuf: AR24 (mod 100000000000002), 10x16, 1 planes
    00:00:00.156 [wlr] [backend/headless/backend.c:29] Starting headless backend
    00:00:00.156 [sway/server.c:260] Running compositor on wayland display 'wayland-2'
    00:00:00.156 [wlr] [types/wlr_output.c:506] Choosing primary buffer format 0x34325241 for output 'WL-1'
    00:00:00.156 [wlr] [render/swapchain.c:105] Allocating new swapchain buffer
    00:00:00.156 [wlr] [render/gbm_allocator.c:130] Allocated 1280x720 GBM buffer (format 0x34325241, modifier 0x100000000000002)
    00:00:00.156 [wlr] [render/vulkan/renderer.c:433] vulkan create_render_buffer: AR24, 1280x720
    00:00:00.156 [wlr] [render/vulkan/texture.c:354] vulkan_import_dmabuf: AR24 (mod 100000000000002), 1280x720, 1 planes
    00:00:00.159 [wlr] [render/swapchain.c:105] Allocating new swapchain buffer
    00:00:00.160 [wlr] [render/gbm_allocator.c:130] Allocated 1280x720 GBM buffer (format 0x34325241, modifier 0x100000000000002)
    00:00:00.160 [wlr] [render/vulkan/renderer.c:433] vulkan create_render_buffer: AR24, 1280x720
    00:00:00.160 [wlr] [render/vulkan/texture.c:354] vulkan_import_dmabuf: AR24 (mod 100000000000002), 1280x720, 1 planes
    00:00:00.170 [wlr] [render/swapchain.c:105] Allocating new swapchain buffer
    00:00:00.170 [wlr] [render/gbm_allocator.c:130] Allocated 1280x720 GBM buffer (format 0x34325241, modifier 0x100000000000002)
    00:00:00.170 [wlr] [render/vulkan/renderer.c:433] vulkan create_render_buffer: AR24, 1280x720
    00:00:00.170 [wlr] [render/vulkan/texture.c:354] vulkan_import_dmabuf: AR24 (mod 100000000000002), 1280x720, 1 planes
    ^C

    PR:             256793
    Reported by:    Evgeniy Khramtsov

 x11-toolkits/wlroots/pkg-message | 1 +
 1 file changed, 1 insertion(+)
Comment 2 Jan Beich freebsd_committer 2021-06-23 20:02:04 UTC
Thanks for reporting. Install vulkan-validation-layers. Once Vulkan renderer is merged upstream the dependency would probably go away or become opt-in for GPU debugging.
Comment 3 commit-hook freebsd_committer 2021-06-23 20:29:48 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=64fbe3630590d931074878a8b886d41cbe8a23e0

commit 64fbe3630590d931074878a8b886d41cbe8a23e0
Author:     Jan Beich <jbeich@FreeBSD.org>
AuthorDate: 2021-06-23 20:26:02 +0000
Commit:     Jan Beich <jbeich@FreeBSD.org>
CommitDate: 2021-06-23 20:29:08 +0000

    x11-wm/sway: backport Vulkan fix

    $ WLR_RENDERER=vulkan sway
    [...]
    Assertion failed: (wlr_texture_is_gles2(wlr_texture)), function gles2_get_texture, file render/gles2/texture.c, line 27.

    PR:             256793

 x11-wm/sway/Makefile | 3 ++-
 x11-wm/sway/distinfo | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)
Comment 4 Evgeniy Khramtsov 2021-06-23 20:34:17 UTC
Created attachment 226016 [details]
stdout_and_stderr

Thanks. After installing vulkan-validation-layers *and* rebuilding both wlroots and sway outside of poudriere, I got further to:

Assertion failed: (wlr_texture_is_gles2(wlr_texture)), function gles2_get_texture, file render/gles2/texture.c, line 27

Removing assert gets me the desktop, currently typing this in Firefox.

No idea if I am using Vulkan renderer correctly, though I sometimes have Z-fighting flickering artifacts in Firefox, background of bugzilla webpage sometimes gets replaced with desktop background and flickers... Also flickering while scrolling in alacritty.

Have a debug log (attaches it to the bug report). Feel free to use it as you want.

Vulkan renderer is currently too experimental for daily usage, switched back to the upstream one and will use that until WLR Vulkan becomes somewhat practical for daily usage.
Comment 5 Evgeniy Khramtsov 2021-06-23 21:16:23 UTC
Z-fighting and flickering disappeared after your last commit, but sometimes sway crashes after starting Firefox both in default and vulkan renderers:

Assertion failed (width > 0), function wlr_texture_from_pixels, file render/wlr_texture.c, line 26

Re-opening because default renderer is regressed now.
Comment 6 Evgeniy Khramtsov 2021-06-23 21:17:49 UTC
(In reply to Evgeniy Khramtsov from comment #5)

> flickering disappeared

Actually, no. In alacritty and mail/mutt there is still flickering while scrolling inbox.
Comment 7 Evgeniy Khramtsov 2021-06-23 21:22:23 UTC
(In reply to Evgeniy Khramtsov from comment #5)

Reverting the commit in x11-wm/sway doesn't help, btw. I'll report if reverting commit in x11-toolkits/wlroots doesn't help too.
Comment 8 Jan Beich freebsd_committer 2021-06-23 21:30:09 UTC
(In reply to Evgeniy Khramtsov from comment #4)
> Removing assert gets me the desktop

comment 3 was late because I mainly dogfood Sway from the development branch, so when landing forgot to test runtime inside jail.

> Z-fighting flickering artifacts in Firefox
[...]
> flickering while scrolling in alacritty.

Wayland-native Vulkan *clients* are also currently broken, reported in https://github.com/swaywm/wlroots/pull/2771#issuecomment-854127254

Try running forcing Xwayland via "env -u WAYLAND_DISPLAY" or "env GDK_BACKEND=x11 WINIT_UNIX_BACKEND=x11".

> too experimental for daily usage

WLR_RENDERER=pixman maybe more stable but probably still requires drm-kmod. Without KMS one would need to resort to framebuffer (via /dev/ttyv0) similar to https://github.com/swaywm/wlroots/pull/2410

Both renderers are currenly mainly for debugging wlroots, its consumers, GPU drivers and downstream integration i.e., for experiments.

(In reply to Evgeniy Khramtsov from comment #5)
> ... sometimes sway crashes after starting Firefox both
> in default and vulkan renderers:
> 
> Assertion failed (width > 0), function wlr_texture_from_pixels,
> file render/wlr_texture.c, line 26

I've downgraded to sway-1.6_3 but can't reproduce. Maybe related to wlroots update because VULKAN option doesn't touch OPENGL code.

$ git di --stat @{u}...origin/pull/2771/head
 .builds/alpine.yml                 |    2 +-
 .builds/archlinux.yml              |    3 +
 .builds/freebsd.yml                |    2 +-
 include/meson.build                |    3 +
 include/render/vulkan.h            |  325 ++++++++
 include/wlr/config.h.in            |    2 +
 include/wlr/render/vulkan.h        |   18 +
 include/wlr/types/wlr_drm.h        |   33 +
 meson.build                        |    1 +
 meson_options.txt                  |    2 +-
 render/meson.build                 |    6 +-
 render/vulkan/meson.build          |   37 +
 render/vulkan/pixel_format.c       |  325 ++++++++
 render/vulkan/renderer.c           | 1560 ++++++++++++++++++++++++++++++++++++
 render/vulkan/shaders/common.vert  |   25 +
 render/vulkan/shaders/meson.build  |   20 +
 render/vulkan/shaders/quad.frag    |   10 +
 render/vulkan/shaders/texture.frag |   25 +
 render/vulkan/texture.c            |  689 ++++++++++++++++
 render/vulkan/util.c               |   93 +++
 render/vulkan/vulkan.c             |  596 ++++++++++++++
 render/wlr_renderer.c              |    9 +
 types/meson.build                  |    1 +
 types/wlr_drm.c                    |  103 +++
 24 files changed, 3886 insertions(+), 4 deletions(-)
Comment 9 Evgeniy Khramtsov 2021-06-23 21:46:11 UTC
(In reply to Evgeniy Khramtsov from comment #5)

Reverted all the recent wlroots-related commits from today and nuked mesa shader cache to be sure nothing is cached. Now Firefox is stable again.

Reverting wlroots 0.14 fixed the following in stdout:

[wlr] [backend/drm/drm.c:1592] drmHandleEvent failed
Comment 10 Evgeniy Khramtsov 2021-06-23 21:54:15 UTC
(In reply to Jan Beich from comment #8)

> Try running forcing Xwayland

Sorry, no. X11=off ftw.

> WLR_RENDERER=pixman maybe more stable but probably still requires drm-kmod

How would I even start Firefox without drm-kmod? UEFI scfb + mesa-devel? I don't think standalone mesa-devel builds llvmpipe or anything related.

> Both renderers are currenly mainly for debugging wlroots

I know. I jump on the footguns so the issues are reported.

About footguns: why did you upgrade wlroots to 0.14 when this is not even merged upstream yet? https://github.com/swaywm/sway/pull/6339
Pull mentions also mentions use with 1.16.1 fixes.

Why not a CFT on freebsd-x11 mailing list before merging this?
Comment 11 Jan Beich freebsd_committer 2021-06-23 22:34:42 UTC
(In reply to Evgeniy Khramtsov from comment #9)
> [wlr] [backend/drm/drm.c:1592] drmHandleEvent failed

Likely exposed by https://github.com/swaywm/wlroots/commit/053ebe7c278b Maybe a bug in drm-kmod or a corner case in sway/wlroots that's specific to your setup. I don't see this locally on Skylake (0x1912) with drm-devel-kmod.

I'd try updating sway 1.6.1/1.7 (not released yet, so use https://github.com/freebsd/freebsd-ports/commit/69d71f21465a for now). If it doesn't help report upstream with debug logs attached.

(In reply to Evgeniy Khramtsov from comment #10)
> why did you upgrade wlroots to 0.14 when this is not even merged
> upstream yet? https://github.com/swaywm/sway/pull/6339

- Sway isn't the only wlroots consumer, so I can't avoid patching
- All cherry-picks were tested months ago
- Before wlroots 0.14.0 there was supposed to be 0.13.1, see https://github.com/swaywm/wlroots/milestone/7
- Vulkan state wasn't clear but upstream rebased just before 0.14.0

> Why not a CFT on freebsd-x11 mailing list before merging this?

Previous CFT didn't get a lot of feedback and was mostly to kill time waiting for wlroots (not sway) release.
Comment 12 Evgeniy Khramtsov 2021-06-23 22:37:25 UTC
(In reply to Jan Beich from comment #11)
(In reply to Evgeniy Khramtsov from comment #9)

Good news:

I unreverted the commits and rebuilt wlroots and sway.

Compositor crash after starting Firefox seems to be gone, maybe nuking mesa shader cache helped. The is still this warning, though:

[wlr] [backend/drm/drm.c:1592] drmHandleEvent failed

Might be related to wlsunset. I don't have the time/wish to check without it.

Feel free to do whatever with this issue, but I think leaving it open for some time would be better.

Thanks for taking your time for this issue.
Comment 13 Evgeniy Khramtsov 2021-06-23 22:50:34 UTC
(In reply to Evgeniy Khramtsov from comment #12)

OK, fine, this should be tested regardless of my mood; wlsunset or not it doesn't matter, drmHandle error is still there.

And no, git am'ing 69d71f21465a.patch and re{building,installing} sway doesn't help.

> I don't see this locally on Skylake (0x1912) with drm-devel-kmod.

Good thing that this is likely not related to the vanilla tree, then.

> If it doesn't help report upstream with debug logs attached.

The issue is in wlroots. Mind sharing a script/simple how-to on how to bisect wlroots? I never bisected things with git before.
Comment 14 Evgeniy Khramtsov 2021-06-23 22:51:29 UTC
(In reply to Evgeniy Khramtsov from comment #13)

s/simple//
Comment 15 Evgeniy Khramtsov 2021-06-23 23:07:01 UTC
I don't want to spend your time more, I can figure it out on my own. Might be a drm-related issue, I also get WARN_ON when loading drm-kmod (see FreeBSDDesktop chat).
Comment 16 Jan Beich freebsd_committer 2021-06-23 23:09:47 UTC
(In reply to Evgeniy Khramtsov from comment #13)
> The issue is in wlroots. Mind sharing a script/simple how-to on how to bisect
> wlroots? I never bisected things with git before.

See comment bug 256188 comment 2 but with cherry-picks mixed in to unbreak build e.g.,

$ cd /path/to/sway
$ (cd subprojects/wlroots; git bisect start 0.14.0 0.13.0)
$ meson setup _build && meson compile -C _build
<build failed>
$ git log origin path/to/affected/file.c
$ git cherry-pick <hash>
$ meson setup _build && meson compile -C _build
$ ./_build/sway/sway # maybe symlink to ~/bin or ~/.local/bin
Comment 17 Evgeniy Khramtsov 2021-06-24 22:40:25 UTC
(In reply to Jan Beich from comment #16)

Did a shortcut before bisecting: reverted wlroots-related commits and applied
https://github.com/swaywm/wlroots/commit/053ebe7c278b
on top of known good 0.13 from ports tree first.

I would like to clarify my comments from before:

00:00:00.988 [ERROR] [wlr] [backend/drm/drm.c:1592] drmHandleEvent failed

0.13: OK
0.13 + 053ebe7c278b: drmHandleEvent failed
0.14: drmHandleEvent failed

Tested with all packages installed from ei branch, then removed all packages and tested with the main branch built using empty make.conf. {drm,wlroots} drmHandleEvent is not related to ei and main branches.

Performance in vkmark and glmark2 does not seem to be affected, VA-API still works. The "drmHandleEvent" warning outputs to stderr only after exiting sway, and seems to be harmless.

The issue is somewhere in libdrm/drm-kmod it seems... Hardware, though it is an ES, is OK, I get the same FPS in benchmarks under Linux now, probably had to do something with locally enabled power management... No DRM related warnings/issues under Fedora 34.

--

Assertion failed (width > 0), function wlr_texture_from_pixels, file render/wlr_texture.c, line 26

This was introduced via new assert checking in https://github.com/swaywm/wlroots/commit/572b5910bbac03b7c0cc20288cadf8f719a9903a

Why would upstream terminate a compositor on this failed assert? Seems like some rogue client may crash a compositor now...

This assert is triggered after "killall firefox" and starting patched mozilla-central Firefox. Browser profile then becomes unusable and needs to be rm'ed for Firefox to start again without crashing sway. I also tried to gather debug info with ei branch and that profile, the debug log does not seem too useful... Is it even worth reporting upstream with this info, or should I somehow get more info?

I tried to reproduce the compositor crash using this borked profile and packages from pkg.FreeBSD.org, but then encountered more bugs after starting sway:

(1) WARNING: Kernel has no file descriptor comparison support: No such file or directory
WARNING: Kernel has no file descriptor comparison support: No error: 0

Starting firefox using pkg.FreeBSD.org results in compositor hard hang even without ".mozilla", it is impossible to switch vts... are mesa-dri and sway from pkg.FreeBSD.org broken for you?

I will try a somewhat less dank Firefox (with X11 and/or 89) and mesa-devel to check if the compositor crash goes away with borked profile later, I feel somewhat demotivated after all of this...
Comment 18 Evgeniy Khramtsov 2021-06-24 22:40:48 UTC
Created attachment 226044 [details]
sway -d log when trying to start firefox
Comment 19 Jan Beich freebsd_committer 2021-06-25 00:09:13 UTC
(In reply to Evgeniy Khramtsov from comment #17)
> "drmHandleEvent" warning outputs to stderr only after exiting sway, and seems to be harmless.

Ah, I see it now. Try reproducing without exiting e.g., switch display on/off either via swaymsg and/or hardware button. 

> Why would upstream terminate a compositor on this failed assert?
> Seems like some rogue client may crash a compositor now...

Someone else reported a similar crash in https://github.com/swaywm/wlroots/pull/2878#issuecomment-832262011 Upstream probably forgot to fix it before 0.14.0.
Note, asserts can be disabled by adding MESON_ARGS+=-Dn_debug=true to x11-toolkits/wlroots/Makefile.local but discouraged by https://github.com/swaywm/wlroots/wiki/Packaging-recommendations

> (1) WARNING: Kernel has no file descriptor comparison support: No such file or directory
> WARNING: Kernel has no file descriptor comparison support: No error: 0

Expected but mostly harmless. Only mesa-devel applied https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6881
For details why upstream needs it see https://gitlab.freedesktop.org/mesa/mesa/-/issues/2882

> are mesa-dri and sway from pkg.FreeBSD.org broken for you?

I can't easily test due to local changes but sway works fine with mesa-dri, tested by removing /usr/local/etc/libmap.d/mesa-devel.conf.
Also, pkg.FreeBSD.org doesn't *yet* have sway 1.6.1 or wlroots 0.14.0.

Both Firefox 89 and Nightly 91 (2021-06-21) appear to work fine on sway with mesa-dri.
Comment 20 Jan Beich freebsd_committer 2021-06-25 00:18:55 UTC
Try filing bugs upstream to get feedback from experts. I only maintain downstream build glue, so can't help with complex issues that are hard to reproduce.

(In reply to Jan Beich from comment #19)
> Upstream probably forgot to fix it before 0.14.0.

Nevermind, see https://github.com/swaywm/wlroots/commit/beae3018cbbb
Comment 21 Evgeniy Khramtsov 2021-06-25 11:14:12 UTC
(In reply to Jan Beich from comment #19)

> Try reproducing without exiting e.g., switch display on/off either via swaymsg and/or hardware button. 

I can't reproduce after several times of swaymsg and hardware disable/enable:
[main.c:300] Found config * for output DP-1
[main.c:352] Destroying output DP-1
[main.c:300] Found config * for output DP-1
[main.c:352] Destroying output DP-1
[main.c:300] Found config * for output DP-1
[main.c:352] Destroying output DP-1

Exiting sway after several times of off/on with either sw or hw off/on results in:
00:00:44.010 [ERROR] [wlr] [backend/drm/drm.c:1592] drmHandleEvent failed
00:00:44.045 [ERROR] [wlr] [backend/drm/atomic.c:39] connector DP-1: Atomic commit failed (modeset): Invalid argument
00:00:44.045 [ERROR] [wlr] [backend/drm/drm.c:1131] connector DP-1: Failed to disable CRTC 84

Also, I could not reproduce with a physical second monitor swaymsg/hw off/on (attached just for this test).

Starting then sway again and repeating all these steps again does not break desktop, performance in glmark2 and vkmark, VA-API seems to be the same for all the tests that I did.

> Upstream probably forgot to fix it before 0.14.0

It seems that upstream fixed the issue that led to that assertion trip in 1.16.1.
No matter what "borked" profile I use, or the amount of "killall firefox", sway session is now stable again, and no assertions happen.

--

To sum it all: issues related to your ports are now resolved, I re-close this bug as "FIXED". Thanks for your help.
Comment 22 Evgeniy Khramtsov 2021-07-27 22:11:57 UTC
> Starting firefox using pkg.FreeBSD.org results in compositor hard hang even without ".mozilla", it is impossible to switch vts... are mesa-dri and sway from pkg.FreeBSD.org broken for you?

I was using the latest packages from pkg.FreeBSD.org when I was testing screen capture via PipeWire. This issue is recently resolved, maybe due to newer mesa. Leaving this note here, I didn't make a proper PR for this at that time.
Comment 23 Jan Beich freebsd_committer 2021-08-03 03:25:10 UTC
https://github.com/freebsd/freebsd-ports/compare/main...jbeich:wlroots-0.15 has updated Vulkan renderer but (as of pull/2771@b92af455) native OpenGL clients (e.g., alacritty) still flicker compared to Xwayland.

(In reply to Evgeniy Khramtsov from comment #21)
> 00:00:44.010 [ERROR] [wlr] [backend/drm/drm.c:1592] drmHandleEvent failed

Should be fixed by https://github.com/swaywm/wlroots/commit/cc8bc0db2065
Comment 24 Evgeniy Khramtsov 2021-08-03 06:01:11 UTC
(In reply to Jan Beich from comment #23)

I confirm, cc8bc0db2065 applied to the current wlroots in ports resolves drmHandleEvent.

I didn't test the snapshot and Vulkan, not interested *for now*, maybe later.
Comment 25 Evgeniy Khramtsov 2021-08-05 04:29:53 UTC
(In reply to Evgeniy Khramtsov from comment #24)

> maybe later

I should have tested it sooner... I fried VRM, and now have to use a device without full Vulkan support (SNB GT2 0x0126). I can report in September to October, maybe this month if not much hardware was damaged.
Comment 26 Evgeniy Khramtsov 2021-08-08 15:10:54 UTC
(In reply to Jan Beich from comment #23)

- 4K VP9 VA-API decoding while windowed takes 3% vs 5% WCPU of sway process.
- Alacritty still flickers, but the rate decreased.
- GTK and Qt applications seem to be working fine.
- Performance regressed [-GL-] to {+VK+} compared:
glmark2:
    GL_RENDERER:   Mesa Intel(R) UHD Graphics 630 (CFL GT2)
    GL_VERSION:    4.6 (Compatibility Profile) Mesa 21.3.0-devel (git-b9129496a29)
=======================================================
[build] use-vbo=false: FPS: [-11152-]{+10635+} FrameTime: [-0.090-]{+0.094+} ms
[build] use-vbo=true: FPS: [-11083-]{+11057+} FrameTime: 0.090 ms
[texture] texture-filter=nearest: FPS: [-10222-]{+9118+} FrameTime: [-0.098-]{+0.110+} ms
[texture] texture-filter=linear: FPS: [-10067-]{+8949+} FrameTime: [-0.099-]{+0.112+} ms
[texture] texture-filter=mipmap: FPS: [-10518-]{+9318+} FrameTime: [-0.095-]{+0.107+} ms
[shading] shading=gouraud: FPS: [-8794-]{+8016+} FrameTime: [-0.114-]{+0.125+} ms
[shading] shading=blinn-phong-inf: FPS: [-8445-]{+8193+} FrameTime: [-0.118-]{+0.122+} ms
[shading] shading=phong: FPS: [-7054-]{+6956+} FrameTime: [-0.142-]{+0.144+} ms
[shading] shading=cel: FPS: [-6205-]{+6605+} FrameTime: [-0.161-]{+0.151+} ms
[bump] bump-render=high-poly: FPS: [-4069-]{+5100+} FrameTime: [-0.246-]{+0.196+} ms
[bump] bump-render=normals: FPS: [-10958-]{+10860+} FrameTime: [-0.091-]{+0.092+} ms
[bump] bump-render=height: FPS: [-10080-]{+10037+} FrameTime: [-0.099-]{+0.100+} ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: [-5045-]{+4067+} FrameTime: [-0.198-]{+0.246+} ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: [-1854-]{+1679+} FrameTime: [-0.539-]{+0.596+} ms
[pulsar] light=false:quads=5:texture=false: FPS: [-9284-]{+7892+} FrameTime: [-0.108-]{+0.127+} ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: [-2019-]{+1778+} FrameTime: [-0.495-]{+0.562+} ms
[desktop] effect=shadow:windows=4: FPS: [-5106-]{+3987+} FrameTime: [-0.196-]{+0.251+} ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: [-2192-]{+1883+} FrameTime: [-0.456-]{+0.531+} ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: [-1966-]{+1860+} FrameTime: [-0.509-]{+0.538+} ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: [-2539-]{+1974+} FrameTime: [-0.394-]{+0.507+} ms
[ideas] speed=duration: FPS: [-6804-]{+5796+} FrameTime: [-0.147-]{+0.173+} ms
[jellyfish] <default>: FPS: [-5324-]{+4291+} FrameTime: [-0.188-]{+0.233+} ms
[terrain] <default>: FPS: [-302-]{+283+} FrameTime: [-3.311-]{+3.534+} ms
[shadow] <default>: FPS: [-5665-]{+5002+} FrameTime: [-0.177-]{+0.200+} ms
[refract] <default>: FPS: [-836-]{+800+} FrameTime: [-1.196-]{+1.250+} ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: [-8079-]{+7089+} FrameTime: [-0.124-]{+0.141+} ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: [-8195-]{+7203+} FrameTime: [-0.122-]{+0.139+} ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: [-7977-]{+7176+} FrameTime: [-0.125-]{+0.139+} ms
[function] fragment-complexity=low:fragment-steps=5: FPS: [-8205-]{+7092+} FrameTime: [-0.122-]{+0.141+} ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: [-8637-]{+6766+} FrameTime: [-0.116-]{+0.148+} ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: [-8086-]{+7158+} FrameTime: [-0.124-]{+0.140+} ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: [-8164-]{+7052+} FrameTime: [-0.122-]{+0.142+} ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: [-8428-]{+7132+} FrameTime: [-0.119-]{+0.140+} ms
=======================================================
                                  glmark2 Score: [-6768-]{+6145+}
=======================================================

vkmark:
    Driver Version: 88088675
=======================================================
[vertex] device-local=true: FPS: [-9498-]{+9216+} FrameTime: [-0.105-]{+0.109+} ms
[vertex] device-local=false: FPS: [-9483-]{+9234+} FrameTime: [-0.105-]{+0.108+} ms
[texture] anisotropy=0: FPS: [-8622-]{+8391+} FrameTime: [-0.116-]{+0.119+} ms
[texture] anisotropy=16: FPS: [-7738-]{+7514+} FrameTime: [-0.129-]{+0.133+} ms
[shading] shading=gouraud: FPS: [-7423-]{+7189+} FrameTime: [-0.135-]{+0.139+} ms
[shading] shading=blinn-phong-inf: FPS: [-7469-]{+7222+} FrameTime: [-0.134-]{+0.138+} ms
[shading] shading=phong: FPS: [-6738-]{+6542+} FrameTime: [-0.148-]{+0.153+} ms
[shading] shading=cel: FPS: [-6503-]{+6310+} FrameTime: [-0.154-]{+0.158+} ms
[effect2d] kernel=edge: FPS: [-5145-]{+5011+} FrameTime: [-0.194-]{+0.200+} ms
[effect2d] kernel=blur: FPS: [-1864-]{+1837+} FrameTime: [-0.536-]{+0.544+} ms
[desktop] <default>: FPS: [-4724-]{+4605+} FrameTime: [-0.212-]{+0.217+} ms
[cube] <default>: FPS: [-12422-]{+12000+} FrameTime: [-0.081-]{+0.083+} ms
[clear] <default>: FPS: [-14578-]{+14155+} FrameTime: [-0.069-]{+0.071+} ms
=======================================================
                                   vkmark Score: [-7862-]{+7632+}
=======================================================

Note, my ports tree is rebased from commit 55cc26acb6
Date: Wed Aug 4 13:59:25 2021 +0800
+ CFLAGS, hardening, and patches

I didn't update to Aug 8, because I am still not sure if I fully
recovered from hw failure and can burn it again via poudriere.

Also, the .patch from GitHub doesn't apply via "git am". Mind to educate me why?
Comment 27 Jan Beich freebsd_committer 2021-08-08 19:30:54 UTC
Thanks for benchmarking. I also see the performance degradation.

(In reply to Evgeniy Khramtsov from comment #26)
> Also, the .patch from GitHub doesn't apply via "git am". Mind to educate me why

PORTREVISION conflict due to recent x11-wm/river update -> fixed.