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
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 @@
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
>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
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
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.
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,
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
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
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
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
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.
>
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.
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.
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.
>
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
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
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
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.
>
>
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
20 matches
Mail list logo
