x264 on ARM

classic Classic list List threaded Threaded
13 messages Options
adr
Reply | Threaded
Open this post in threaded view
|

x264 on ARM

adr
Hello,
multimedia/x264 assembly will generate bus errors.
Tested with ffmpeg.

Regards,
adr.
================================================
RCS file: /cvs/ports/multimedia/x264/Makefile,v
retrieving revision 1.51
diff -u -p -r1.51 Makefile
--- Makefile    22 Jul 2019 06:56:33 -0000      1.51
+++ Makefile    9 Aug 2019 17:21:46 -0000
@@ -40,7 +40,7 @@ CONFIGURE_ARGS+=--prefix=${PREFIX} \
                 --disable-lavf \
                 --disable-swscale

-.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "powerpc"
+.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "powerpc" || ${MACHINE_ARCH} == "arm"
  CONFIGURE_ARGS+=--disable-asm
  .endif

Reply | Threaded
Open this post in threaded view
|

Re: x264 on ARM

Jeremie Courreges-Anglas-2

Please CC the port maintainer,

On Fri, Aug 09 2019, adr <[hidden email]> wrote:
> Hello,
> multimedia/x264 assembly will generate bus errors.

Can you provide more details?  It's good if people can reproduce issues
and understand the issue at hand before commiting anything...

> Tested with ffmpeg.
>
> Regards,
> adr.
> ================================================
> RCS file: /cvs/ports/multimedia/x264/Makefile,v
> retrieving revision 1.51
> diff -u -p -r1.51 Makefile
> --- Makefile    22 Jul 2019 06:56:33 -0000      1.51
> +++ Makefile    9 Aug 2019 17:21:46 -0000
> @@ -40,7 +40,7 @@ CONFIGURE_ARGS+=--prefix=${PREFIX} \
>                 --disable-lavf \
>                 --disable-swscale
>
> -.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "powerpc"
> +.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "powerpc" || ${MACHINE_ARCH} == "arm"
>  CONFIGURE_ARGS+=--disable-asm
>  .endif
>

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

adr
Reply | Threaded
Open this post in threaded view
|

Re: x264 on ARM

adr
> Please CC the port maintainer,

He knows about it already.

> Can you provide more details?  It's good if people can reproduce issues
> and understand the issue at hand before commiting anything...

arm + bus error + assembly this is going to be must all the time
access of words or half words unaligned.  You are going to have a
lot of these problems porting assembly from gas to llvm, specially
with old code.

Regards,
adr.

Reply | Threaded
Open this post in threaded view
|

Re: x264 on ARM

Stuart Henderson
On 2019/08/11 19:48, adr wrote:
> arm + bus error + assembly this is going to be must all the time
> access of words or half words unaligned.  You are going to have a
> lot of these problems porting assembly from gas to llvm, specially
> with old code.

Switching a bunch of ports to gcc is not the answer.

adr
Reply | Threaded
Open this post in threaded view
|

Re: x264 on ARM

adr
> Switching a bunch of ports to gcc is not the answer.

The answer is to talk with the developers of each of these ports
and show them the problems they'll find with llvm, so maybe they
re-implement the assembly optimization following the ARM conventions.
That was my advice to the ffmpeg and x264 maintainer. Or study each
of these ports and rewrite yourself the code, if you like.  Meanwhile,
the only thing you can do is to disable the assembly if that is
possible, or try to compile it with gcc. That was the case of mupdf.

If that is for you "Switching a bunch of ports to gcc"... good for
you.

I'm been using OpenBSD for two weeks or so. I'm just reporting
things that I found wrong. If what I receive in response is this
kind of pedantic statements, don't worry, I will not report anything
more.

Reply | Threaded
Open this post in threaded view
|

Re: x264 on ARM

Jeremie Courreges-Anglas-2
On Sun, Aug 11 2019, adr <[hidden email]> wrote:
>> Switching a bunch of ports to gcc is not the answer.
>
> The answer is to talk with the developers of each of these ports
> and show them the problems they'll find with llvm, so maybe they
> re-implement the assembly optimization following the ARM conventions.
> That was my advice to the ffmpeg and x264 maintainer. Or study each
> of these ports and rewrite yourself the code, if you like.

> Meanwhile,
> the only thing you can do is to disable the assembly if that is
> possible,

Looks like the sanest alternative indeed.

> or try to compile it with gcc. That was the case of mupdf.

--8<--
revision 1.89
date: 2019/07/30 15:59:48;  author: sthen;  state: Exp;  lines: +7 -5;  commitid: a8XfL4d8h3TFscT1;
build MuPDF with gcc on armv7, problem reported by adr at sdf.org in
https://marc.info/?l=openbsd-ports&m=156448467232400&w=2 - Bus error at
runtime - suspect possible alignment issue?
-->8--

It's not clear to me that assembly code is the culprit here.

> If that is for you "Switching a bunch of ports to gcc"... good for you.
>
> I'm been using OpenBSD for two weeks or so. I'm just reporting
> things that I found wrong. If what I receive in response is this
> kind of pedantic statements, don't worry, I will not report anything
> more.

I agree with Stuart's statement.  It may be terse but I don't find it
pedantic.

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

Re: x264 on ARM

Stuart Henderson
In reply to this post by adr
On 2019/08/11 23:48, adr wrote:

> > Switching a bunch of ports to gcc is not the answer.
>
> The answer is to talk with the developers of each of these ports
> and show them the problems they'll find with llvm, so maybe they
> re-implement the assembly optimization following the ARM conventions.
> That was my advice to the ffmpeg and x264 maintainer. Or study each
> of these ports and rewrite yourself the code, if you like.  Meanwhile,
> the only thing you can do is to disable the assembly if that is
> possible, or try to compile it with gcc. That was the case of mupdf.
>
> If that is for you "Switching a bunch of ports to gcc"... good for you.
>
> I'm been using OpenBSD for two weeks or so. I'm just reporting
> things that I found wrong. If what I receive in response is this
> kind of pedantic statements, don't worry, I will not report anything
> more.

As you are new to OpenBSD I think you may be coming at this without
some of th existing knowledge of the situation, OpenBSD/armv7 runs the
cpu in strict alignment mode whereas it is fairly common for some
software to assume that ARM does not have such a requirement, there has
already been some discussion about changing that.

https://marc.info/?t=151933630600003&r=1&w=2

adr
Reply | Threaded
Open this post in threaded view
|

Re: x264 on ARM

adr
In reply to this post by Jeremie Courreges-Anglas-2
> It's not clear to me that assembly code is the culprit here.

No, I bet it is their memory managment functions.

> I agree with Stuart's statement.  It may be terse but I don't find it
> pedantic.

And I agree too, that's why I found it pedantic.
Any way, I'm out of place here.

Reply | Threaded
Open this post in threaded view
|

Re: x264 on ARM

Stuart Henderson
On 2019/08/12 14:12, adr wrote:
> > It's not clear to me that assembly code is the culprit here.
>
> No, I bet it is their memory managment functions.
>
> > I agree with Stuart's statement.  It may be terse but I don't find it
> > pedantic.
>
> And I agree too, that's why I found it pedantic.
> Any way, I'm out of place here.

The problem with changing things in each port is that it will take
forever (apart from anything else there are very few ports developers
with armv7 machines) and it's likely a never ending battle. Few port
maintainers are going to be able to test diffs. And disabling asm is
unappealing on an arch which needs as much help with speed as it can
get.

Looking in list archives I see patrick@ mentioned about running in
strict alignment mode and the ecosystem not being really able to support
that in reply to your earlier post about x264. And as you can see in the
thread I linked to earlier there is some appetite and an initial diff
for changing this. It's likely that such a change will result in the
most things being fixed for the least effort.

Reply | Threaded
Open this post in threaded view
|

Re: x264 on ARM

Theo de Raadt-2
Stuart Henderson <[hidden email]> wrote:

> On 2019/08/12 14:12, adr wrote:
> > > It's not clear to me that assembly code is the culprit here.
> >
> > No, I bet it is their memory managment functions.
> >
> > > I agree with Stuart's statement.  It may be terse but I don't find it
> > > pedantic.
> >
> > And I agree too, that's why I found it pedantic.
> > Any way, I'm out of place here.
>
> The problem with changing things in each port is that it will take
> forever (apart from anything else there are very few ports developers
> with armv7 machines) and it's likely a never ending battle. Few port
> maintainers are going to be able to test diffs. And disabling asm is
> unappealing on an arch which needs as much help with speed as it can
> get.
>
> Looking in list archives I see patrick@ mentioned about running in
> strict alignment mode and the ecosystem not being really able to support
> that in reply to your earlier post about x264. And as you can see in the
> thread I linked to earlier there is some appetite and an initial diff
> for changing this. It's likely that such a change will result in the
> most things being fixed for the least effort.

Let me explain why we've tried to run strict alignment on as many
platforms as possible.

It is because some architectures are data strict alignment.  We could
emulate non-strict on the strict platforms, and make them all non-strict
alignment.  That is the direction Linux has been going, and that's why
so much code is written that way now.

There are a few problems with this:

Some architectures have a cheap toggle to do non-strict in hardware, or
can be emulated inexpensive.  But on other architectures the emulation
is very expensive: read the instruction, decode it, and then emulate the
behaviour, all the time ignoring the lack of atomicity introduced by the
emulation which may cause other problems later in threaded code and
such.

So let's say we do non-strict on some architectures, but not others?

Sooner or later, the strict architectures are going to be the only ones
which get burned by a software change which assumes all the world is a vax.
(vax was non-strict)

Some of the strict-alignment platforms are slower, and due to having a
smaller user base, repair for these issues will take longer.  Eventually
support for those architectures becomes extinct.

And becoming extinct is a bad thing.  We are using the breadth of
architecture variety as a "canany in the coalmine" approach towards
identifying bugs which may affect more than just one architecture.
Running on lots of tier2 architectures improves quality for our tier1
platforms, this is no joke.

In the end, even amd64 will suffer from the lack of testing diversity.

We could give up on strict-alignment on arm64, but the consequences is
other architectures will become 'load bearing' for this issue.

First they came for strict alignment on arm64, but I wasn't arm64 so
I didn't say anything.

Reply | Threaded
Open this post in threaded view
|

Re: x264 on ARM

Stuart Henderson
On 2019/08/12 08:46, Theo de Raadt wrote:

> Stuart Henderson <[hidden email]> wrote:
>
> > On 2019/08/12 14:12, adr wrote:
> > > > It's not clear to me that assembly code is the culprit here.
> > >
> > > No, I bet it is their memory managment functions.
> > >
> > > > I agree with Stuart's statement.  It may be terse but I don't find it
> > > > pedantic.
> > >
> > > And I agree too, that's why I found it pedantic.
> > > Any way, I'm out of place here.
> >
> > The problem with changing things in each port is that it will take
> > forever (apart from anything else there are very few ports developers
> > with armv7 machines) and it's likely a never ending battle. Few port
> > maintainers are going to be able to test diffs. And disabling asm is
> > unappealing on an arch which needs as much help with speed as it can
> > get.
> >
> > Looking in list archives I see patrick@ mentioned about running in
> > strict alignment mode and the ecosystem not being really able to support
> > that in reply to your earlier post about x264. And as you can see in the
> > thread I linked to earlier there is some appetite and an initial diff
> > for changing this. It's likely that such a change will result in the
> > most things being fixed for the least effort.
>
> Let me explain why we've tried to run strict alignment on as many
> platforms as possible.
>
> It is because some architectures are data strict alignment.  We could
> emulate non-strict on the strict platforms, and make them all non-strict
> alignment.  That is the direction Linux has been going, and that's why
> so much code is written that way now.
>
> There are a few problems with this:
>
> Some architectures have a cheap toggle to do non-strict in hardware, or
> can be emulated inexpensive.  But on other architectures the emulation
> is very expensive: read the instruction, decode it, and then emulate the
> behaviour, all the time ignoring the lack of atomicity introduced by the
> emulation which may cause other problems later in threaded code and
> such.
>
> So let's say we do non-strict on some architectures, but not others?
>
> Sooner or later, the strict architectures are going to be the only ones
> which get burned by a software change which assumes all the world is a vax.
> (vax was non-strict)
>
> Some of the strict-alignment platforms are slower, and due to having a
> smaller user base, repair for these issues will take longer.  Eventually
> support for those architectures becomes extinct.
>
> And becoming extinct is a bad thing.  We are using the breadth of
> architecture variety as a "canany in the coalmine" approach towards
> identifying bugs which may affect more than just one architecture.
> Running on lots of tier2 architectures improves quality for our tier1
> platforms, this is no joke.
>
> In the end, even amd64 will suffer from the lack of testing diversity.
>
> We could give up on strict-alignment on arm64, but the consequences is
> other architectures will become 'load bearing' for this issue.
>
> First they came for strict alignment on arm64, but I wasn't arm64 so
> I didn't say anything.
>

I fully understand this. (And that aligned access is faster on !strict
arches).

With arm64 the machines are fast enough, there's a bit more developer
interest, and I think there probably *are* enough in hands of ports
devs that we maybe able to cope with this approach.

For armv7 that the OP is using, it's going to be hard for ports to cope.

adr
Reply | Threaded
Open this post in threaded view
|

Re: x264 on ARM

adr
In reply to this post by Stuart Henderson
> And disabling asm is unappealing on an arch which needs as much
> help with speed as it can get.

Even worst if you have to play video without hw acc.

I thought that the decision of using --no_unaligned_access was a
security one, but it seems from the thread that is more like a
legacy one.  So there is no point to talk to someone to change
his/her code to take into account the arm conventions when unalignment
access is not permitted, if there is no real reason for doing that.

Look, don't get me wrong. I'm not a guy that is been using this OS
some days and now he things is a member of the developer core. I
didn't want to have this conversation, because I don't have any
idea of the things that are being going on. I'm just trying to
build my cabin here, without bothering anyone trying to figure out
things by myself.

The first thing I recommended to the ffmpeg maintainer, I think it
was in a private mail, was to talk to some developer of the arm
port because I knew that this wasn't an small issue.

Regards,
adr

Reply | Threaded
Open this post in threaded view
|

Re: x264 on ARM

Theo de Raadt-2
adr <[hidden email]> wrote:

> > And disabling asm is unappealing on an arch which needs as much
> > help with speed as it can get.
>
> Even worst if you have to play video without hw acc.
>
> I thought that the decision of using --no_unaligned_access was a
> security one, but it seems from the thread that is more like a
> legacy one.

No.  It is neither.