[FFmpeg-devel] [PATCH] ARM: NEON optimised vector_fmul

[Måns Rullgård]

Laurent Desnogues wrote:
> On Tue, Aug 26, 2008 at 1:07 PM, M?ns Rullg?rd <mans at mansr.com> wrote:
>>
>> I thought about that, and I agree it should be made optional somehow.
>> I can't think of a reliable way to detect it, so I guess a configure
>> flag will have to do.
>
> Indeed I don't think there's any correct way to detect revision on
> OMAP3.  Perhaps the OMAP3 ES id of newer revisions will be
> > 2.2 which would ensure post r1p1 Cortex-A8.  If that's the case,
> grepping dmesg could provide auto-detection of revision.
> Anyway, having a configure flag to override auto-detection would
> be handy.

I've been told ES3.0 will have a fixed A8, and that it's due later this
year.  The Beagle rev C should be getting the new OMAP3 revision, at
which point I'll be sure to get my mitts on one.

I'd rather not use OS-specific hacks, so a configure flag is probably
the only realistic option anyway.  Even if runtime revision detection
were available and reliable, it would require two copies of the code
or tricky runtime code patching (I got odd looks last time I did that
at work :-).

>> I also have no post-r1p1 hardware to test on.
>
> According to this message:
>
> http://www.gp32x.com/board/index.php?s=&showtopic=43698&view=findpost&p=639365
>
> the new revisions are available.  You could perhaps get in touch
> with DJWillis, who makes the Linux "distro" for Pandora, and
> MWeston who designs the hardware, to get them to test FFmpeg.

Sounds like TI are sampling the new silicon, so it should be available
to Beagle and Pandora alike soon enough, provided TI stay on schedule.

It's not a difficult thing to code, so I'll probably just add it as a
configure option, and make sure it generates correct code in both cases.

-- 
M?ns Rullg?rd
mans at mansr.com