After a `guix package -m manifest.scm`, everything seems to be fine.
I guess one of the programs I was using was still depending on llvm 6.
Problem solved!
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Are you using GuixSD or Guix on top of another distro?
It seemed to me that when my caches were empty the first application I'd run
would cause the shaders to be rebuilt with whatever version of llvm that
application was built with.
And it also seems that the issue goes both ways, so if you run an
Hello Guix,
ison writes:
> Ok this solution has resolved the issue for me on a newly updated system.
>
> Note that deleting both shader caches was required, and also if the caches get
> rebuilt on a new generation and then I try to boot into an older previously
> working generation then that gen
Ok this solution has resolved the issue for me on a newly updated system.
Note that deleting both shader caches was required, and also if the caches get
rebuilt on a new generation and then I try to boot into an older previously
working generation then that generation will display graphics artifac
On Fri, May 10, 2019 at 02:11:48PM +0200, Marius Bakke wrote:
> Can you try to delete "$HOME/.cache/mesa_shader_cache/" and see if see
> if it makes a difference?
That did it! At least for the user installed applications I was testing with it
seems to have resolved the issue.
I also deleted the o
OK, thanks for the tip! Will do when I'm back on Tuesday.
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Pierre Neidhardt writes:
> Hmm, not sure it's related to user data since GDM fails to display.
Also try to `rm -rf /var/lib/gdm/.cache/mesa_shader_cache`.
signature.asc
Description: PGP signature
ison writes:
> Sorry I neglected to mention that I actually tried upgrading mesa earlier and
> it
> didn't resolve the problem. Neither upgrading mesa (I tried 18.3.6 and some
> 19.*
> version) nor downgrading (back to 18.3.1) would fix it, all rebuilds still
> resulted in artifacts. I suppose
Pierre Neidhardt writes:
> Hi,
>
> My last system reconfigure dates back to April 17th and works
> flawlessly.
> Yesterday I ran a new one and X / GDM don't start up properly:
>
> - I can guess bits and pieces of the GDM interface but the screen is
> torn asunder by the most epic artifacts (gre
Thanks for investigating this!
So does anyone know if there is a good reason to keep llvm 7 for Mesa?
Was it just updated for the sake of updating? (Which is usually a good
reason, admittedly :p)
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Sorry I neglected to mention that I actually tried upgrading mesa earlier and it
didn't resolve the problem. Neither upgrading mesa (I tried 18.3.6 and some 19.*
version) nor downgrading (back to 18.3.1) would fix it, all rebuilds still
resulted in artifacts. I suppose it's because the dependency o
On Thu, 9 May 2019 19:59:17 -0600
ison wrote:
> Thanks for helping to narrow down the issue. Although I'm not sure where to go
> from here.
Maybe try mesa 18.3.6, maybe someone fixed it there already.
Apparently there's also mesa 19.0.4.
If it can't be fixed otherwise, we can compile the old mes
I think you're right. I just tried different versions of llvm with the game
minetest (testing with minetest now since it compiles much faster than mpv)
Trying with llvm@7.0.1 using the command:
guix environment --ad-hoc minetest --with-input=llvm=llvm@7.0.1
results in the same corrupt video issue
Might be related to LLVM because it's sometimes used by shader compilers.
pgpvxm1cinyET.pgp
Description: OpenPGP digital signature
I can confirm this exact same issue with the same video card, RX 580, and my
last attempt to update pulled in kernel 5.0.13. When the login screen shows up
the screen is horribly corrupt, nothing is even recognizable as being a part of
the normal login screen, just random colored lines all over the
15 matches
Mail list logo
