Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1148767 > unrolled thread

Bug#448105: mplayer: Illegal Instruction in init_audio_codec

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#448105: mplayer: Illegal Instruction in init_audio_codec Lorenzo <plorenzo@disroot.org> - 2023-06-05 00:20 +0200
    Bug#448105: mplayer: Illegal Instruction in init_audio_codec Reimar Döffinger <Reimar.Doeffinger@gmx.de> - 2023-06-05 20:40 +0200
      Bug#448105: mplayer: Illegal Instruction in init_audio_codec Lorenzo <plorenzo@disroot.org> - 2023-06-06 15:10 +0200
        Bug#448105: mplayer: Illegal Instruction in init_audio_codec Reimar Döffinger <Reimar.Doeffinger@gmx.de> - 2023-06-06 15:30 +0200
          Bug#448105: mplayer: Illegal Instruction in init_audio_codec Reimar Döffinger <Reimar.Doeffinger@gmx.de> - 2023-06-06 20:30 +0200
            Bug#448105: mplayer: Illegal Instruction in init_audio_codec Reimar Döffinger <Reimar.Doeffinger@gmx.de> - 2023-06-06 21:30 +0200

#1148767 — Bug#448105: mplayer: Illegal Instruction in init_audio_codec

Hi Reimar,

On Fri, 26 Oct 2007 10:32:55 +0200 Reimar =?iso-8859-1?Q?D=F6ffinger?=
<Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:

> AltiVec runtime detection never worked reliably (compiler dependant)
> and the way it was detected in libavcodec was an unacceptable hack.
> Since the PowerPC architecture does not offer a sane way to
> distinguish between with and without Altivec we now treat them as
> different architectures, meaning you need a different build for each.
> 
> Greetings,
> Reimar Döffinger
> 

The above was 16 years ago; on Debian powerpc list a couple a
ways to do runtime detection were suggested

https://lists.debian.org/debian-powerpc/2023/06/msg00030.html

could you please check again if it's still unfeasible to detect altivec
at runtime in mplayer/mencoder?

Thanks,
Lorenzo

[toc] | [next] | [standalone]

#1148808

> On 5 Jun 2023, at 00:08, Lorenzo <plorenzo@disroot.org> wrote:
> 
> Hi Reimar,
> 
[...]
> 
> The above was 16 years ago; on Debian powerpc list a couple a
> ways to do runtime detection were suggested
> 
> https://lists.debian.org/debian-powerpc/2023/06/msg00030.html
> 
> could you please check again if it's still unfeasible to detect altivec
> at runtime in mplayer/mencoder?

While it's still plenty messy, FFmpeg has runtime detection of altivec, and MPlayer itself has no altivec code itself.
But I don't think it works, the problem is the compiler options:
- to be able to compile code using altivec and have the optimizations available, -maltivec must be used
- if -maltivec is used, even normal C code will use altivec instructions, thus crashing

The first thing to check would be whether FFmpeg (ffplay in particular) works (supporting both altivec optimized playback and not crashing without altivec).
But in the end I don't know if it is realistic to change the situation:
- implementing and testing is hard since not much hardware is around (and at least some build system adjustments will be needed)
- without altivec, the machines are so slow, certainly nothing but ancient video files will be playable, putting the benefit a bit in question of running on non-altivec machines
- building the base code without -maltivec will make MPlayer slower on machines with altivec like G4, which might be enough to push them over the edge to not be able to play certain videos that they can otherwise

So maybe it is possible to get to work now, but probably separate builds would remain the better approach.
On the plus side, if FFmpeg works, and since Debian links MPlayer to FFmpeg dynamically, --disable-altivec should be all that is needed - assuming the performance degradation on altivec enabled systems mentioned above is considered acceptable.

Best regards,
Reimar

[toc] | [prev] | [next] | [standalone]

#1148853

Thanks for looking at this again

On Mon, 5 Jun 2023 20:33:15 +0200 =?utf-8?Q?Reimar_D=C3=B6ffinger?=
<Reimar.Doeffinger@gmx.de> wrote:

> While it's still plenty messy, FFmpeg has runtime detection of
> altivec, and MPlayer itself has no altivec code itself. But I don't
> think it works, the problem is the compiler options:
> [ ... ]
> So maybe it is possible to get to work now, but probably separate
> builds would remain the better approach. On the plus side, if FFmpeg
> works, and since Debian links MPlayer to FFmpeg dynamically,
> --disable-altivec should be all that is needed - assuming the
> performance degradation on altivec enabled systems mentioned above is
> considered acceptable.

Disable altivec for everyone doesn't seem a good compromise to me, I'm
going to build twice on powerpc and let the user decide which one to use

Best,
Lorenzo

> 
> Best regards,
> Reimar
> 
> 
> 

[toc] | [prev] | [next] | [standalone]

#1148856

> On 6 Jun 2023, at 14:57, Lorenzo <plorenzo@disroot.org> wrote:
> 
> Thanks for looking at this again
> 
>> So maybe it is possible to get to work now, but probably separate
>> builds would remain the better approach. On the plus side, if FFmpeg
>> works, and since Debian links MPlayer to FFmpeg dynamically,
>> --disable-altivec should be all that is needed - assuming the
>> performance degradation on altivec enabled systems mentioned above is
>> considered acceptable.
> 
> Disable altivec for everyone doesn't seem a good compromise to me, I'm
> going to build twice on powerpc and let the user decide which one to use

To be clear: as MPlayer has no hand-written altivec, I I expect only a maybe 5-10% or so degradation (pure guess), the most performance critical stuff in FFmpeg should not be affected.
So --disable-altivec is not obviously unacceptable, but I do think separate builds would be better, as 10% can matter on these systems.
(I am rather mystified how FFmpeg handles this, since as said the runtime check code does not look like it would actually work - if it does not work, a separate non-altivec MPlayer build will not help as it will still crash for ~90% of media files, just in FFmpeg codecs now instead of MPlayer itself - is there a good way to test any of this?).

[toc] | [prev] | [next] | [standalone]

#1148885

> On 6 Jun 2023, at 15:17, Reimar Döffinger <Reimar.Doeffinger@gmx.de> wrote:
> 
>> Disable altivec for everyone doesn't seem a good compromise to me, I'm
>> going to build twice on powerpc and let the user decide which one to use
> 
> To be clear: as MPlayer has no hand-written altivec, I I expect only a maybe 5-10% or so degradation (pure guess), the most performance critical stuff in FFmpeg should not be affected.

So, funny thing. I installed debian-ppc on qemu g3 emulated system.
What did I find out:
- xfce4 crashes with illegal instruction
- ffmpeg does not crash, but only because it is built with --disable-altivec which makes it basically unusably slow on e.g. G4 systems.
So there is no winning.

So for practical purposes, you can just as well compile MPlayer with --disable-altivec, since FFmpeg is compiled this way the speed of MPlayer won't make a relevant difference.

On the details what goes on here (skip if you do not like rants):
What is the source of all these issues? gcc
In the past, -maltivec was used to just enable support for altivec intrinsics.
However gcc then changed and generated Altivec instructions even from plain C code.
While that makes sense in a way, it meant code everywhere broke on non-altivec systems.
This includes FFmpeg.
For packages important enough/depending on maintainer, the "solution" was to disable altivec completely, making these programs vastly slower on Altivec enabled computers.
Others like xfce4 and MPlayer only work on PPC systems with Altivec.
Without extensive code and build system changes, this seems now an unsolvable situation.
Unless someone adds an option like -faltivec that Apple had, which allows the intrinsics but not compiler generation of altivec instructions (I think gcc maintainers at one point said they could not do that).
clang has both -faltivec and -maltivec, but neither are properly documented, so who knows if they would help here or not.
Either way, without someone EXTREMELY motivated, this seems not solvable (switching to clang with -faltivec if it were to work just MIGHT have a chance).
I guess it's a lesson in not buying into architectures where the creators don't have their shit together enough to get even the basics right - and upstreamed... (I guess it's mostly solved by PPC being as good as dead now).
(don't get me wrong, I still sometimes boot my old MacMini with G4 and update to latest Debian, but I think the ISA is just dead at this point, unfortunately).

Sorry for the long rant,
Reimar

[toc] | [prev] | [next] | [standalone]

#1148893

Hi Fabian!

> On 6 Jun 2023, at 21:14, Fabian Greffrath <fabian@greffrath.com> wrote:
> 
> I remember that back then, when powerpc was still a release architecture in Debian, we built two flavors of the ffmpeg libraries -- one with altivec and one without:
> 
> https://salsa.debian.org/multimedia-team/ffmpeg/-/blob/debian/master/debian/rules#L184
> 
> That code is still there, so I wonder why your linker doesn't pick up the flavor that matches your processor's instruction set.

Ah, thanks, that is probably just me being dumb since I was testing on a G3 only!
I guess that only works for libraries though, no such auto-selection for executables, right?
Seems ffmpeg and ffplay are built only without altivec (which is kind of ok, and as said might be ok for MPlayer but would be nice to check).

Thanks for the hint,
Reimar

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web