Le Tue, Feb 21, 2023 at 07:47:59PM +1100, Jonathan Gray a écrit : > 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 ...
ok great, if its only that... but looking a bit, this path can be user-controlled via MESA_SHADER_CACHE (previously MESA_GLSL_CACHE) env vars (https://www.phoronix.com/news/Mesa-Shader-Cache-Env-Var ?), so do we want to allow for that ? i guess this doesnt use XDG_CACHE_HOME, so the below diff might be enough ? no need for unveils in other processes ? pledge.main already have flock but i dunno if its necessary from within mesa.. diff --git a/Makefile b/Makefile index 2b1bbf0..46435d9 100644 --- a/Makefile +++ b/Makefile @@ -8,7 +8,7 @@ MOZILLA_PROFDATA_TASKID=E9TKAEdPRnqlck2oxO6HjQ MOZILLA_BRANCH = release MOZILLA_PROJECT = firefox MOZILLA_CODENAME = browser -REVISION = 0 +REVISION = 1 WRKDIST = ${WRKDIR}/${MOZILLA_DIST}-${MOZILLA_DIST_VERSION:C/b[0-9]*//} HOMEPAGE = https://www.mozilla.org/firefox/ diff --git a/files/unveil.main b/files/unveil.main index efeb954..ea504b8 100644 --- a/files/unveil.main +++ b/files/unveil.main @@ -44,6 +44,7 @@ ~/.icons r ~/.pki rwc ~/.sndio rwc +~/.cache/mesa_shader_cache rwc ~/.terminfo r ~/.mozilla rwc
