Re: Bug#830180: PowerPC without altivec causes crash
On Sun, Nov 12, 2017 at 12:27:54AM +0100, Riccardo Mottola wrote:
> Hi,
>
>
>
> On 12/11/2017 00:03, Gabriel Paubert wrote:
> > I hope that you don't parse /proc/cpuinfo to know the capabilities of
> > your CPU. There is a better way to do this, namely use getauxval(3).
>
> jpeg-turbo was doing exactly that and getauxval() was refused, read the bug
> discussion.
>
> >
> > Speaking of Altivec, there is another library that claims to be compiled
> > for Altivec but is actually compiled for VSX: libx265, which means that
> > I get crashes with "illegal instruction" on my G5.
> >
> > I had a look at the source code, and it's really confusing, many
> > functions have Altivec in the name, but it's actually using vsx
> > instructions. A disassembly of the code reveals it: just grep
> > for "vs[0-9]" patterns.
>
> I don't have a G4 or G5 to test altivec with a free Unix, my PPC
> development is currently done only on my G3 iBook with Linux and Mac with a
> G3 (iBook) and G4 (PowerBook).
> What uses libx265?
>
Firefox for videos, among others, but I don't know the details (the
dependency chain is a mess).
> Firefox is almost unusable on my iBook: scarce ram and also almost not
> present video acceleration (old ATI Mach64 is very slow with current X11)
> limit it do a couple of easier programs and as a test machine more than
> daily use.
Firefox is completely unusable on my G4 (1.67GHz G4 Powerbook), and
usable on my quad G5 (64 bit version).
In both cases, there is also the problem that it will crash easily (almost
any right mouse button click) if you put the display in 16 bit depth. But
opengl refuses to work with 24 bit depth for other reasons.
I think the reason for the crash in firefox is that the assertion at
line 323-324 of gfx/2d/DataSurfaceHelpers.cpp triggers when in 16 bit
depth mode.
Gabriel
Reply to: