[FFmpeg-devel] Fix Altivec detection on Linux.

Reimar Döffinger Reimar.Doeffinger
Thu Mar 20 12:24:37 CET 2008


On Thu, Mar 20, 2008 at 10:56:12AM +0000, David Woodhouse wrote:
> On Wed, 2008-03-19 at 19:50 +0100, Reimar D?ffinger wrote:
> > On Wed, Mar 19, 2008 at 06:33:20PM +0000, David Woodhouse wrote:
> > > On Wed, 2008-03-19 at 16:30 +0100, Reimar D?ffinger wrote: 
> > > > For Ubuntu the existing but disabled check via mfspr IMO is a very much
> > > > better solution.
> > > 
> > > Why so?
> > 
> > Well, because the code is there and very simple.
> 
> And disabled by default, because it apparently causes SIGILL on kernels
> older than 2.6.17 where mfspr isn't emulated by the kernel (although
> wasn't that supported earlier than 2.6.17?)

It actually is enabled when compiling from MPlayer, and on all operating
systems when building with runtime CPU-detection.
It is not enabled for FFmpeg because it has no way to disable runtime
CPU-detection.
I do not like this method at all because it works on only exactly one
OS.
In my personal opinion the "right" solution is to choose one single way
of detecting AltiVec, and tell anyone where it does not work to fix
their OS. And if they don't manage to do that, tell them to choose
architecture that has hardware designers/OS developers with better
interoperability skills.

> And it also involves a hard-coded list of PVR values which is already
> out of date (or just wrong). That kind of hardware knowledge doesn't
> live in the library -- especially when the kernel may disable Altivec
> for userspace anyway, even when the hardware supports it.

The kernel could then adjust the PVR value. Or they could just introduce
another emulated instruction that actually behaves in a way that makes
sense.
You know, with all that CPU detection mess, despite the fact that it
just can't be, I can't help thinking "is every single person working on
the PPC (both hardware and OS level software) stuff a complete idiot
with not the slightest clue of portable programming?".
So, end of rant. I'll try to keep quite about this now and leave the
decision to someone else whom it actually affects.

Greetings,
Reimar D?ffinger




More information about the ffmpeg-devel mailing list