Re: ffmpeg & x264 on arm
On 10/16/2020 9:27 AM, a...@sdf.org wrote:
Hi Brad,
we talked about this last year (and tested some other codecs).
Can you apply this?
Ya, I know. I had intended to get a board up and running. Thanks to some
help from jsg@ I have my M2 Ultra board now running with an SSD and I
am checking out the tree to take a look at your diff plus some other related
bits.
Regards,
adr.
==
multimedia/x264:
--- Makefile.orig Thu Oct 15 09:02:38 2020
+++ MakefileThu Oct 15 09:04:07 2020
@@ -42,7 +42,8 @@
--disable-swscale
.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "mips64" || \
-${MACHINE_ARCH} == "mips64el" || ${MACHINE_ARCH} == "powerpc"
+${MACHINE_ARCH} == "mips64el" || ${MACHINE_ARCH} == "powerpc" || \
+${MACHINE_ARCH} == "arm"
CONFIGURE_ARGS+=--disable-asm
.endif
==
graphics/ffmpeg:
--- Makefile.orig Fri Oct 16 14:20:11 2020
+++ MakefileThu Oct 15 13:55:18 2020
@@ -130,6 +130,10 @@
--objcc="/usr/bin/false" \
--optflags="${OPTFLAGS}"
+.if ${MACHINE_ARCH} == "arm"
+CONFIGURE_ARGS+=--disable-asm
+.endif
+
CONFIGURE_ENV+= TERM=${TERM} \
TMPDIR=${WRKBUILD}
ffmpeg & x264 on arm
Hi Brad,
we talked about this last year (and tested some other codecs).
Can you apply this?
Regards,
adr.
==
multimedia/x264:
--- Makefile.orig Thu Oct 15 09:02:38 2020
+++ MakefileThu Oct 15 09:04:07 2020
@@ -42,7 +42,8 @@
--disable-swscale
.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "mips64" || \
-${MACHINE_ARCH} == "mips64el" || ${MACHINE_ARCH} == "powerpc"
+${MACHINE_ARCH} == "mips64el" || ${MACHINE_ARCH} == "powerpc" || \
+${MACHINE_ARCH} == "arm"
CONFIGURE_ARGS+=--disable-asm
.endif
==
graphics/ffmpeg:
--- Makefile.orig Fri Oct 16 14:20:11 2020
+++ MakefileThu Oct 15 13:55:18 2020
@@ -130,6 +130,10 @@
--objcc="/usr/bin/false" \
--optflags="${OPTFLAGS}"
+.if ${MACHINE_ARCH} == "arm"
+CONFIGURE_ARGS+=--disable-asm
+.endif
+
CONFIGURE_ENV+=TERM=${TERM} \
TMPDIR=${WRKBUILD}
Re: x264 on ARM
Pay attention, it's not legacy, there are real actual reasons to do that. Read again thru Theo's mail, carefully. Pay attention, this wasn't a response to Theo's mail. What I get from Theo's email is a detailed description of a cross-platform OS robustness issue, given limited testing resources. Legacy would suggest to me more of a historical burden that could go away if the offending software were removed. Anyways, this particular example seems like it should be simple. Huh??? I really, really don't want to have this conversation, but somehow words of mine appears here out of context. The word legacy doesn't have anything to do with the mail that Theo de Raadt sent. It was a response I sent to Stuart Henderson talking about __this__ thread he sent me: https://marc.info/?t=15193363063&r=1&w=2 My impression was that the port was first develped for an architecture before ARMv6, without hardware support for unaligned memory access, that is why I used the word legacy. I know, the mail arrived after that, but sometimes I have to stop composing a mail to do something, then I came back, etc. Now, about "Theo's mail" (good title for a movie, by the way): I understand the advantages of the diverse environment, and I read before about the good it has done to the OpenBSD code, specially sparc. So yes, I understand that you like to have ports with strict alignment memory access. But that has to be made when the architecture demands it. I know that aligned access would be faster, and if you craft code made explicitly with that in mind, and if what the code does, it does it without loosing performance for being restricted in an aligned paradigm, the code will be faster. But you install an OS to run code in it, and even if that code is made taking on account strict alignment, I doubt that the performance, especially with multimedia applications would be better with the jiggle that code would have to do in software to achieve the same it would be done in hardware using unaligned access. And permitting unaligned access doesn't mean that you can't choose when to use it. Do not clang or gcc take on acount that when placing variables for example? Maybe that was the situation before or even with ARMv6, I don't know, but I don't think that is the case for the processors you support in the armv7 port. I mean, even for the stm32f the arm library uses unaligned access for performance reasons. So the only reason I see here is the canary in the coal mine. But you are cutting legs and stapling wings to this poor bastard... That is my opinion. Now let me out of this. Please. adr.
Re: x264 on ARM
>On Tue, Aug 20, 2019 at 2:47 PM adr wrote: >> > Pay attention, it's not legacy, there are real actual reasons to do that. >> > Read again thru Theo's mail, carefully. >> >> Pay attention, this wasn't a response to Theo's mail. > >What I get from Theo's email is a detailed description of a >cross-platform OS robustness issue, given limited testing resources. > >Legacy would suggest to me more of a historical burden that could go >away if the offending software were removed. > >Anyways, this particular example seems like it should be simple. Huh???
Re: x264 on ARM
On Tue, Aug 20, 2019 at 2:47 PM adr wrote: > > Pay attention, it's not legacy, there are real actual reasons to do that. > > Read again thru Theo's mail, carefully. > > Pay attention, this wasn't a response to Theo's mail. What I get from Theo's email is a detailed description of a cross-platform OS robustness issue, given limited testing resources. Legacy would suggest to me more of a historical burden that could go away if the offending software were removed. Anyways, this particular example seems like it should be simple. -- Raul
Re: x264 on ARM
Pay attention, it's not legacy, there are real actual reasons to do that. Read again thru Theo's mail, carefully. Pay attention, this wasn't a response to Theo's mail.
Re: x264 on ARM
On Mon, Aug 12, 2019 at 03:27:55PM +, adr 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. 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. Pay attention, it's not legacy, there are real actual reasons to do that. Read again thru Theo's mail, carefully.
Re: x264 on ARM
adr 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.
Re: x264 on ARM
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
Re: x264 on ARM
On 2019/08/12 08:46, Theo de Raadt wrote: > Stuart Henderson 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.
Re: x264 on ARM
Stuart Henderson 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.
Re: x264 on ARM
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.
Re: x264 on ARM
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.
Re: x264 on ARM
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=15193363063&r=1&w=2
Re: x264 on ARM
On Sun, Aug 11 2019, 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, 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
Re: x264 on ARM
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.
Re: x264 on ARM
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.
Re: x264 on ARM
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.
Re: x264 on ARM
Please CC the port maintainer,
On Fri, Aug 09 2019, adr 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
> --- Makefile22 Jul 2019 06:56:33 - 1.51
> +++ Makefile9 Aug 2019 17:21:46 -
> @@ -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
x264 on ARM
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
--- Makefile22 Jul 2019 06:56:33 - 1.51
+++ Makefile9 Aug 2019 17:21:46 -
@@ -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
