no sse2 support on jetson tx1

Hi
i’m trying to compile this library: “GitHub - uzh-rpg/fast: FAST corner detector by Edward Rosten
but i received this error:
#error “This file requires SSE2 support. Check your compiler flags.”
This is the code of the .cpp file:
#ifndef SSE2

error “This file requires SSE2 support. Check your compiler flags.”

#else

include <emmintrin.h>

#endif

and this is like i change the cmakelist.txt
SET(CMAKE_CXX_FLAGS_RELEASE “${CMAKE_CXX_FLAGS} -O3 -mtune=cortex-a57 -march=armv8-a+simd”)
but it isn’t correct

There is a correct configuration or the nvidia jetson don’t support this?

SIMD and its SSE extensions are architecture-dependent. This extension works only with desktop CPUs, so no other CPU can support this (including Jetson ARM CPUs). If you were to port this you’d probably be doing a conversion to NEON (or perhaps just going straight to a CUDA version).

thanks for your reply
but on arm cpu (like on raspberry pi) it works with this line code:
SET(CMAKE_CXX_FLAGS_RELEASE “${CMAKE_CXX_FLAGS} -O3 -mfpu=neon -march=armv7-a”)
while jetson tx1 is aarch64 architecture (not simple arm)

The TX1 CPU is ARMv8-a. This implies 64-bit (arm64 or aarch64) with a new instruction set that differs from the older 32-bit ARMv7. The aarch64-capable CPU has a compatibility mode which is 32-bit (referred to as ARMv8 without the “-a”). This compatibility mode allows execution of any NEON or ARMv7 code previously referred to as armhf (this mode is entered via an interrupt so it is not possible to execute a mixed set of 32-bit and 64-bit simultaneously). However, compiling code specifically for this 32-bit mode (ARMv8) can produce code which is not backwards compatible on an older CPU which is specifically ARMv7 or armhf…small differences in the newer ARMv8 32-bit CPU cannot be run on the older CPU (much of that code would work on older armhf, but small pieces would cause failure).

The “-mfpu=neon” is irrelevant if building on an actual ARMv8 compiler since all ARMv8 require NEON support (the correct compiler has no such option). The architecture would not be armv7-a, but instead (depending on software) armhf or arm32. Specific references to ARMv7 would fail on an ARMv8 compiler (which is what a JTX1 uses…so if your compiler was intended to work with older software those options would work, but if compiling from something intended for the JTX1, then those options would fail). The NEON support is there, it just can’t be referred to as optional.

I suspect you are referring specifically to user space programs (versus kernel space). For user space it is not just a matter of whether the CPU and kernel support NEON and arm32/armhf. Once you go to user space you must also install 32-bit user space environment for any 32-bit code to work or compile. This includes 32-bit compatible linker and support libraries, not just 32-bit capable CPU or kernel support. When installing L4T R23.x you are installing a 64-bit kernel plus 32-bit-only user space. Once you reach R24.1 you can still install a 32-bit user space, but most installations of R24.1 will install 64-bit user space without 32-bit compatibility. In R24.2 there is no 32-bit user space sample rootfs (this is a purely 64-bit user space without options for 32-bit rootfs).

The more subtle point is that in all of those rootfs cases, 32-bit or 64-bit on various L4T version, only a single user space of that 32-bit or 64-bit is installed. That version is referred to as the native mode. Once you install a 64-bit native mode the installation of a backwards-compatible 32-bit user space is possible if you have a lot of patience…this is a foreign architecture though, and not the native architecture. Simultaneously supporting both native 64-bit and a 32-bit foreign architecture can be difficult…this is not an easy task.

On a desktop computer the existence of 32-bit x86 and 64-bit x86_64 has been around a long time. The compiler in a desktop environment supports both modes in a single compiler, but this is not true for ARM…you have to specify two separate compilers to deal with mixed native and foreign architecture (along with all of the complications). This is why you won’t currently find any off-the-shelf installation on 64-bit ARM which also makes 32-bit (and thus NEON which is tied to 32-bit) compatibility available with simple installation steps. You can do it, but it gets complicated and is not well tested.