$ 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.
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(+)
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.
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(-)
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.
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.
(In reply to Evgeniy Khramtsov from comment #5) > flickering disappeared Actually, no. In alacritty and mail/mutt there is still flickering while scrolling inbox.
(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.
(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(-)
(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
(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?
(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.
(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.
(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.
(In reply to Evgeniy Khramtsov from comment #13) s/simple//
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).
(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
(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...
Created attachment 226044 [details] sway -d log when trying to start firefox
(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.
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
(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.
> 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.
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
(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.
(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.
(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?
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.
Upstream has merged WLR_RENDERER=vulkan. If you can still reproduce usability issues (e.g., flickering, graphical artifacts, app crashes) report upstream, hopefully before 0.15.0 is released. For easier debugging maybe confirm in a minimal nested session (e.g., Sway/Vulkan with empty config on a dogfooded Sway/OpenGL). For now, ignore performance difference (unless it's very bad like >20%) as upstream postponed further Vulkan improvements until 0.16.0 or later. Even in the best case Vulkan maybe slightly slower than OpenGL at least on Intel Gen < 12 (e.g., vkmark "vertex" vs. glmark2 "build").
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=a3837318d0a66be81377892d5e3a65d78f00b2d2 commit a3837318d0a66be81377892d5e3a65d78f00b2d2 Author: Jan Beich <jbeich@FreeBSD.org> AuthorDate: 2021-11-28 17:43:46 +0000 Commit: Jan Beich <jbeich@FreeBSD.org> CommitDate: 2021-11-28 17:59:58 +0000 x11-toolkits/wlroots: don't require vulkan-validation-layers PR: 256793 x11-toolkits/wlroots/Makefile | 3 ++- x11-toolkits/wlroots/distinfo | 2 ++ x11-toolkits/wlroots/pkg-message | 1 - 3 files changed, 4 insertions(+), 2 deletions(-)
wlroots 0.15.0 has landed in ports 2af7805da5c5.