Re: llvmpipe - was: Re: Updated Debian Ports installation images 2025-12-06

On Thu, 2026-04-23 at 01:30 +1000, Damien Stewart wrote:
> On 21/4/26 3:12 pm, John Paul Adrian Glaubitz wrote:
> > The LLVM error messages don't mean that the binaries were built with LL=
VM/Clang
> > but that LLVM is being used for software-rendering. The underlying soft=
ware is
> > called llvmpipe.
> >=20
> > See:https://docs.mesa3d.org/drivers/llvmpipe.html
> >=20
> > Since LLVM does not support all features on 32-bit PowerPC, llvmpipe ha=
s some
> > issues on this architecture.
>=20
> Thanks for the info. See, I found the same thing when I first looked up=
=20
> this "LLVM error relocation type not implemented" message a while back.=
=20
> Most results returned related to Clang and/or linker. I'm not trying to=
=20
> compile, I'm running a binary, so that's too late. Even now, most=20
> results talk about linkers and not graphics even when using "llvmpipe"=
=20
> as a search term. Clearly, the error is too vague and LLVMPipe needs to=
=20
> mention itself, and how it relates to graphics. Then it would be more=20
> obvious. Typical computer errors. And something like "LLVM" when=20
> unpacked describes a hardware emulator to me, so these people should=20
> come up with better names. :-?

Well, to be fair, LLVM really a compiler but a library. You get the compile=
r when
you combine a frontend like rustc, clang or flang with LLVM. This modularit=
y allows
one to use the LLVM library very flexible and at some point someone came up=
 with
the idea to use it for software rendering.

I'm not really an expert on Mesa or llvmpipe, but I think this kind of resu=
sability
is very useful and allows developers to save a lot of engineering efforts t=
hat
would otherwise be needed to implement a code generation backend for a cert=
ain
architecture.

GCC actually copied the idea with libgccjit which will eventually and hopef=
ully
allow the Rust compiler to support many more architectures not supported by
LLVM.

> So, most G4 Mac people using newest graphic cards without full drivers=
=20
> would be affected, while G5 people should be fine when needing a=20
> fallback. This would explain why mine breaks. My kernel is 64 bit but I=
=20
> found out I had a 32 bit userland, so must have accidentally picked the=
=20
> wrong install image. My Debian 64 has no such issues, if just a bit slow=
=20
> using software rendering, since I don't have a HD6000 or 3d supported=20
> card plugged in.

I think you should not be affected when using hardware acceleration since t=
hen
you wouldn't be using llvmpipe in the first place. If you're seeing LLVM er=
rors
when running graphics applications, it means you're using software renderin=
g,
not hardware rendering.

So, you should figure out why hardware rendering is not enable on your mach=
ine.

> Slightly off topic, but at this point, I wonder if AI could be used for=
=20
> good use to scrape through the AMD driver sources and locate endian=20
> issues. Then suggest how to fix. I'm thinking AI could be good for=20
> finding endian issues in frequently updated code that's not practical to=
=20
> fix by hand for every software update.

It should already be good enough. Why not give it a try yourself?

Adrian

--=20
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913