support AArch64 Neon SIMD about fftw3 HOT 13 CLOSED

Can you provide a patch? We don't have an aarch64 development environment, so I am not quite sure what to do. Is neon part of the standard aarch64 ISA, or is it an extension that requires special compiler flags?

from fftw3.

It is beyond me. I have googled this problem. I think Ubuntu community is working on it.

from fftw3.

matteo-frigo: yes NEON is part of the standard ISA (with double the registers, you'll like it!!!).

I just found this issue, I'm currently working it around by setting NEON_CFLAGS=-D__ARM_NEON__

from fftw3.

I don't know much about ARMv8, but there does seem to be some level of
support in gcc 4.9.2. Taken from the manpage:

   -mfpu=name
       This specifies what floating-point hardware (or hardware

emulation)
is available on the target. Permissible names are: vfp, vfpv3,
vfpv3-fp16, vfpv3-d16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16,
neon,
neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16, neon-vfpv4, fp-armv8,
neon-fp-armv8, and crypto-neon-fp-armv8.

       If -msoft-float is specified this specifies the format of

floating-
point values.

       If the selected floating-point hardware includes the NEON

extension
(e.g. -mfpu=neon), note that floating-point operations are not
generated by GCC's auto-vectorization pass unless
-funsafe-math-optimizations is also specified. This is because
NEON hardware does not fully implement the IEEE 754 standard for
floating-point arithmetic (in particular denormal values are
treated as zero), so the use of NEON instructions may lead to a
loss of precision.

Can someone please explain why this is not sufficient?

On Mon, Jan 12, 2015 at 9:53 AM, Jérôme Carretero [email protected]
wrote:

matteo-frigo: yes NEON is part of the standard ISA (with double the
registers, you'll like it!!!).

I just found this issue, I'm currently working it around by setting
NEON_CFLAGS=-DFAKE_NEON_FLAGS

—
Reply to this email directly or view it on GitHub
#25 (comment).

from fftw3.

Actually I was blocked further when trying to build (using an Android aarch64-linux-android sysroot); can someone build for 64-bit ARM at all?

from fftw3.

Figured out that there is no simd-support code for aarch64... which explains the issue. I guess that should be contributed ;)

from fftw3.

I have closed it by mistake. @zougloub thanks for rooting the cause.

from fftw3.

I've added support for double-precision Neon (available in aarch64) in my fork, https://github.com/rdolbeau/fftw3. It should asupport both SP and DP version on aarch64. Only tested in Qemu so far. Any report welcome.
Upd: pass 'make check' on the X-Gene 1.

from fftw3.

@rdolbeau, wow, looks nice. @matteo-frigo, can you take a look?

(Dealing with MIT's Technology Licensing Office may be a hassle for incorporating nontrivial patches, however, unless you are willing to make a copyright assignment to MIT. The problem is that MIT still sells non-GPL licenses for FFTW.)

from fftw3.

I've also added a cycle counter in my fork for better planning (using the virtual counter register, see the commit message for details; thanks to ARM for the informations). Any report/comment/criticism welcome.

from fftw3.

Aarch64 is supported in the current trunk.

from fftw3.

Does this mean that FFTW releases have support for double precision FFT operations using optimized NEON instructions? How can I compile it to do so? @rdolbeau

When compiling with --enable-neon you get the error message configure: error: NEON requires single precision.

from fftw3.

Armv7 (32 bits such such as A7,A9,A15, ...) do not have hardware support for double-precision NEON, and gives the message above.

Aarch64 (64 bits, such as A53, A72, ...) is required to get double-precision NEON support with --enable-neon.

from fftw3.