Le Tue, 21 Feb 2023 12:15:31 +0100, Antoine Jacoutot <ajacou...@bsdfrog.org> a écrit :
> On Tue, Feb 21, 2023 at 12:00:06AM +1100, Jonathan Gray wrote: > > 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. > > Wow, that makes a crazy improvement! > Running a full blown GNOME right now and I can definitely tell the difference. > Thanks :-) > > > > Index: lib/mesa/src/util/disk_cache.c > > =================================================================== > > RCS file: /cvs/xenocara/lib/mesa/src/util/disk_cache.c,v > > retrieving revision 1.13 > > diff -u -p -r1.13 disk_cache.c > > --- lib/mesa/src/util/disk_cache.c 28 Jan 2023 08:56:53 -0000 1.13 > > +++ lib/mesa/src/util/disk_cache.c 20 Feb 2023 12:42:45 -0000 > > @@ -80,11 +80,6 @@ disk_cache_create(const char *gpu_name, > > uint8_t cache_version = CACHE_VERSION; > > size_t cv_size = sizeof(cache_version); > > > > -#ifdef __OpenBSD__ > > - /* default to no disk shader cache to avoid pledge violations in > > chromium */ > > - return NULL; > > -#endif > > - > > if (!disk_cache_enabled()) > > return NULL; > > > > > +1, with this diff, it's day and night when using GNOME
