Porting neon assembly to AdvSIMD Aarch64

[Peter Robinson]

On Mon, Aug 11, 2014 at 3:06 PM, Ilya Palachev <i.palachev at samsung.com> wrote:
> Hi, all.
>
> Video and audio decoding for different formats in Gstreamer and its plugins
> is highly optimized for arm architecture using NEON intrinsics and direct
> ARMv7 NEON assembly .
> For different user applications such optimizations help to improve
> performance.
>
> I wonder whether anybody has tried to port such assembly to Aarch64
> architecture.
>
> At the beginning of 2014 the neon check has been disabled by William Grant
> for aarch64 build to make possible the build of gstreamer for aarch64.
> https://bugzilla.gnome.org/show_bug.cgi?id=712367
>
> And here - https://bugzilla.gnome.org/show_bug.cgi?id=722091 - Peter
> Robinson has said that
>
> In theory the aarch64 NEON implementation is backwards compatible with ARMv7
> NEON
>
> It's not completely true. Armv8-a architecture is backwards compatible with
> armv7l only at application level (Aarch32 execution mode).
> That means that if we have Aarch64 OS with firmware that provides the set of
> libraries that the application "X" depends on: compiled both for armv7l and
> aarch64, and we have to versions of application "X": for arvm7l and aarch64,
> then you can launch both these applications (in different processes). But
> it's impossible to run arvm7l code during the execution of the aarch64 code.
> It requires the change of the exception level (see official documentation).

If you take my point out of context it's not entirely true, my point
was NEON C code written for the NEON SIMD Engine on ARMv7 should run
without code changes on the NEON2 (or what ever it's called) when it's
recompiled for ARMv8/aarch64.

> So the question is:
> Does the development plan of gstreamer include such porting to aarch64,
> since it's needed for better performance?

It could probably do with further optimisation and run time detection
for the most optimal code path.

Peter