(cc -= release team, += Mesa)
On Fri, 15 Dec 2023 at 18:52:58 +0100, Aurelien Jarno wrote:
> On 2023-12-15 11:11, Simon McVittie wrote:
> > On Thu, 14 Dec 2023 at 21:59:19 +0800, Bo YU wrote:
> > > 10/12 gnome-shell:shell / perf-basic FAIL 189.57s exit status 1
> > > 11/12 gnome-shell:shell / perf-closeWithActiveWindows FAIL 76.88s exit status 1
> > > 12/12 gnome-shell:shell / perf-headlessStart FAIL 100.23s exit status 1
> >
> > It seems likely that this is a bug in Mesa or LLVM (specifically, Mesa's
> > software rendering drivers) rather than a bug in GNOME Shell.
...
> > I notice from the Mesa changelog that recent uploads of Mesa enabled
> > LLVM JIT on riscv64. Does that solve this bug?
>
> No it doesn't, and actually made things worse, many packages like gtk4
> will now FTBFS. I reported the issue as #1058759.
That's unfortunate, and I hope that can be resolved soon.
> Work to support orcjit in
> mesa is be done by the riscv community and will eventually benefit
> all architectures when mcjit support gets removed from LLVM.
That's great to hear, and sounds like a much more sustainable thing for
the longer term.
> Alternatively it softpipe should be
> improved to provide an exact same rendering as llvmpipe.
Some of the bugs I've seen involving mips64el have been "this reftest is
misrendered by softpipe", and I'm willing to disable those on softpipe
architectures, especially if a porter for the relevant architecture can
confirm that on real hardware, everything is fine.
The ones I'm more concerned about are the bugs of the form "this test-case
crashes when using softpipe", and as far as I can tell, the gnome-shell
test failures under discussion in this particular bug report are in
that category: with softpipe, the Shell doesn't render the wrong pixels
successfully, it just doesn't work at all. But maybe I'm reading the
log wrong?
smcv