On Tue, Feb 21, 2023 at 10:07:08AM +0100, Landry Breuil wrote:
> 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..
If I only change unveil.gpu or unveil.content the cache is populated.
So the cache is used in at least unveil.main unveil.gpu unveil.content .
>
> 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
>
