On Tue, Feb 21, 2023 at 09:09:49AM +0100, Landry Breuil wrote: > Le Tue, Feb 21, 2023 at 01:28:45PM +1100, Jonathan Gray a écrit : > > On Mon, Feb 20, 2023 at 08:17:35PM +0100, Robert Nagy wrote: > > > On 20/02/23 14:56 +0100, Landry Breuil wrote: > > > > Le Tue, Feb 21, 2023 at 12:00:06AM +1100, Jonathan Gray a écrit : > > > > > On Mon, Feb 20, 2023 at 11:31:23AM +0100, Antoine Jacoutot wrote: > > > > > > On Mon, Feb 20, 2023 at 02:06:34PM +1100, Jonathan Gray wrote: > > > > > > > On Sun, Feb 19, 2023 at 01:34:41PM +0100, Antoine Jacoutot wrote: > > > > > > > > Hi. > > > > > > > > > > > > > > > > There seems to be a regression with mesa that makes gtk+4 > > > > > > > > application very slow > > > > > > > > to start. > > > > > > > > By default the GSK renderer uses OpenGL. > > > > > > > > As a workaround, you can temporarily use this to go back to the > > > > > > > > cairo renderer > > > > > > > > which makes gtk+4 applications fast again: > > > > > > > > > > > > > > > > export GSK_RENDERER=cairo > > > > > > > > > > > > > > What hardware is this on? Is there a Mesa or gtk bug for it? > > > > > > > > > > > > See dmesg below. > > > > > > > > > > > > > When did this behaviour start? Before the gtk update that > > > > > > > recently > > > > > > > went in? Does it occur with GSK_RENDERER=vulkan? > > > > > > > GSK_RENDERER described in > > > > > > > https://docs.gtk.org/gtk4/running.html#gsk_renderer > > > > > > > > > > > > It did not happen on my previous amd ryzen. > > > > > > As soon as I switched to the new intel laptop, I was that bug > > > > > > (exact same > > > > > > installation, I rsync'd everything). > > > > > > > > > > > > It does *not* appear with GSK_RENDERER=vulkan but that renderer is > > > > > > buggy (not > > > > > > built by default) and segfaults on a regular basis. > > > > > > > > > > > > > There is > > > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/5113 > > > > > > > which briefly touches on shader cache. We disable the shader > > > > > > > cache to be able to uses pledge(2). > > > > > > > > > > > > Yes, that is the bug I was looking into. > > > > > > > > > > Here is a xenocara diff to enable the shader cache. > > > > > It is created in ~/.cache/mesa_shader_cache/ > > > > > > > > > > On an Intel system (x250 with Broadwell) launching gtk4-demo results > > > > > in > > > > > a 1.6M cache. The time to a window appearing is noticeably shorter > > > > > running it again after that. > > > > > > > > > > The various firefox and chromium ports will need to change > > > > > unveil/pledge policies to use it. Chromium at least still runs but > > > > > there are multiple warnings that directories can't be created. > > > > > > This just needs an unveil of that directory in the gpu process and > > > an flock pledge for chromium to use it. Seems okay to me. I think > > > this should go in. > > > > So chromium and firefox commits go in first, then the Mesa part a > > few days later? > > i'll play dumb, but which firefox commit ? > > to my understanding so far, that mesa shader cache only has an impact on > gtk+4 apps. A i wrong and if enabled it will also have an impact on > gtk+3 apps, in which case what needs to be done ?
Web browsers use OpenGL/shaders outside of the use in gtk4. > > build mesa with your diff, try to run firefox, see it crash/fail to do > something, add random things to unveil/pledge ? for example on firefox startup: Failed to create /usr/users/jsg/.cache/mesa_shader_cache/cd for shader cache (No such file or directory)---disabling. Failed to create /usr/users/jsg/.cache/mesa_shader_cache/79 for shader cache (No such file or directory)---disabling. Failed to create /usr/users/jsg/.cache/mesa_shader_cache/bb for shader cache (No such file or directory)---disabling. ... For firefox this path is also required in unveil.main ...
