Le Tue, Feb 21, 2023 at 09:08:34PM +1100, Jonathan Gray a écrit : > 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 .
right, i'll add it to the three of them then, and then figure out later (or not...) if some are unneeded. Not sure the gpu process is used at all those days, i lost track. thanks ! Landry
