ERROR: This system does not support SSE4_1
Please check that RTE_MACHINE is set correctly.
Is there any way to bypass this flag in DPDK?
DPDK version 17.08.1
OS : fedora 20
Is there any way to bypass this flag in DPDK?
Sure, the DPDK needs to be compiled without SSE4.1, so it will not require SSE to be present at runtime.
If we do not care about portability, the best way to deal with the issue is to compile DPDK with RTE_MACHINE="native", i.e. using x86_64-native-linuxapp-gcc config (or similar).
This will use the most CPU capabilities your local host supports, but might somewhat limit the portability to other CPUs.
To make it more portable, set RTE_MACHINE="snb" to compile DPDK for SandyBridge CPUs and newer.
The full list of supported machines are listed here:
http://dpdk.org/browse/dpdk/tree/mk/machine
EDIT:
According to DPDK 17.08 Release Notes:
Starting with version 17.08, DPDK requires SSE4.2 to run on x86. Previous versions required SSE3.
That was due to the new vPMD functionality, as described in the patch discussion.
dpdk-stable-XX\mk\machine\native\rte.vars.mk
--ifeq ($(SSE42_SUPPORT),)
++ifneq ($(SSE42_SUPPORT),)
Related
A question related to specifying target CPU with Arm Fortran Compiler (armflang)?
How to set target CPU?
Is there any way for armflang to autodetect the CPUs?
Which CPUs does it support?
Arm Fortran Compiler (armflang) supports -mcpu= option. When set to -mcpu=native, it tries to detect the host CPU. This enables armflang to make CPU specific optimizations as compared to generic Arm related optimizations.
The 18.4 release supports following targets
Cavium ThunderX2 (-mcpu=thunderx2t99)
Hisilicon Hi1616 (-mcpu=cortex-a72)
Qualcomm Falkor hardware (-mcpu=falkor)
Softiron (-mcpu=cortex-a57)
Cavium ThunderX (-mcpu=thunderx)
What is the correct way to compile Boost without AVX/AVX2 on a machine that supports AVX?
OS: Ubuntu
Compiler GCC 5.4
Boost version: 1.66
By default the compiler will generate code that does not require AVX/AVX2, and Boost does not require AVX/AVX2 by default either. So, you don't need to do anything to make the compiled code compatible with CPUs lacking AVX.
Note that this doesn't mean that AVX instructions won't be generated at all. In some places Boost libraries perform runtime detection of CPU features and use AVX only if available. For example, Boost.Log does that.
I'm building an application that uses OpenCV that will run on a variety of Windows computers (using Win7, Win8, Win10).
Now I have discovered that my application crashes randomly at some computers. After a lot of googling I have realized that enabling SSE3 in OpenCV can cause Illegal Instruction crashes on processors that doesn't support SSE3.
http://answers.opencv.org/question/18001/illegal-instruction-when-running-any-compiled-opencv-demo-binary-sse3-flag/
https://bugs.launchpad.net/linuxmint/+bug/1258259
So this is my question: Does anyone of you know which processor flags are "safe". I understand what they do, but I don't know how common it is for a processor to support, for instance, SSE42.
In other words: Which of these flags do you think I should disable when I compile OpenCV?
OCV_OPTION:
ENABLE_SSE
ENABLE_SSE2
ENABLE_SSE3
ENABLE_SSSE3
ENABLE_SSE41
ENABLE_SSE42
ENABLE_POPCNT
ENABLE_AVX
ENABLE_AVX2
ENABLE_FMA3
I have an intel i7 haswell cpu, and I would like to start exploring OpenCL development. In particular, I am interested to run OpenCL code on the integrated GPU.
Unfortunately, by now, I was not able to find any SDK on Intel's site..
May you provide some links, together with a summary of the current status of OpenCL tools for the Linux platform and Intel hardware?
I think this would be useful to many other people..
Thanks a lot!
Intel does not provide free support for OpenCL on their iGPUs under Linux - you have to buy the Intel Media Server Studio, minimum $499. On Windows, you can download a free driver to get OpenCL capability for the iGPU: https://software.intel.com/en-us/articles/opencl-drivers#philinux.
Note that you can use any OpenCL SDK you want - it doesn't have to be Intel. The SDK is only useful for building your program. For running an OpenCL program, you need an appropriate runtime (driver) from the manufacturer. The AMD SDK will give you access to the CPU as an OpenCL device, but not the iGPU.
There is Open Source OpenCL implementation for Intel GPUs on Linux called Beignet, maintained by bunch of guys from Intel.
Sadly, couldn't personally try and check if Your's GPU is properly supported, but on their wiki they states:
Supported Targets
4th Generation Intel Core Processors "Haswell", need kernel patch currently, see the "Known Issues" section.
Beignet: self-test failed" and almost all unit tests fail. Linux 3.15 and 3.16 (commits f0a346b to c9224fa) enable the register whitelist by default but miss some registers needed for Beignet.
This can be fixed by upgrading Linux, or by disabling the whitelist:
# echo 0 > /sys/module/i915/parameters/enable_cmd_parser
On Haswell hardware, Beignet 1.0.1 to 1.0.3 also required the above workaround on later Linux versions, but this should not be required in current (after 83f8739) git master.
So, it's worth a shoot. Btw, it worked well on my 3rd generation HD4000.
Also, toolchain and driver in question includes bunch of GPU-support test cases.
For anyone who comes across this question as I did, the existing answers have some out-of-date information; Intel now offers free drivers for Linux on the site posted above: https://software.intel.com/en-us/articles/opencl-drivers#philinux
The drivers themselves are only supported on 5th, 6th and 7th gen Core processors (and a bunch of other Celerons and Xeons, see link), with earlier processors such as 4th gen still needing the Media Server Studio.
However, they now offer a Linux Community version of Media Server Studio which is free to download.
They also have a Driver Support Matrix for Intel Media SDK and OpenCL which has some useful information about compatibility: https://software.intel.com/en-us/articles/driver-support-matrix-for-media-sdk-and-opencl
You may check intel open source Beignet OpenCL library: http://arrayfire.com/opencl-on-intel-hd-iris-graphics-on-linux/
For me (ubuntu 15.10 + Intel i5 4th generation GPU) it works quite well.
P.S.
Also I must say that I managed to download "media server" for linux a couple of months ago (but didn't used it yet). So you may check it also.
Suppose you have a cross-compilation tool-chain that produces binaries for the ARM architecture.
Your tool-chain is like this (running on a X86_64 machine with Linux):
arm-linux-gnueabi-gcc.exe : for cross-compilation for Linux, running on ARM.
arm-gcc.exe : for bare-metal cross-compilation targeting ARM.
... and the plethora of other tools for cross-compilation on ARM.
Points that I'm interested in are:
(E)ABI differences between binaries (if any)
limitations in case of bare-metal (like dynamic memory allocations, usage of static constructors in case of C++, threading models, etc)
binary-level differences between the 2 cases in terms of information specific to each of them (like debug info support, etc);
ABI differences is up to how you invoke the compiler, for example GCC has -mabi and that can be one of ‘apcs-gnu’, ‘atpcs’, ‘aapcs’, ‘aapcs-linux’ and ‘iwmmxt’.
On bare-metal limitations for various runtime features exists because someone hasn't provided them. Be them initializing zero allocated areas or providing C++ features. If you can supply them, they will work.
Binary level differences is also up to how you invoke compiler.
You can check GCC ARM options online.
I recently started a little project to use a Linux standard C library in a bare-metal environment. I've been describing it on my blog: http://ellcc.org/blog/?page_id=289
Basically what I've done is set up a way to handle Linux system calls so that by implementing simplified versions of certain system calls I can use functions from the standard library. For example, the current state for the ARM implements simplified versions of read(), readv(), write(), writev() and brk(). This allows me to use printf(), fgets(), and malloc() unchanged.
I'm my case, I use the same compiler for targeting Linux and bare-metal. Since it is clang/LLVM based, I can also use the same compiler to target other processors. I'm working on a bare-metal example for the Mips right now.
So I guess the answer is that there doesn't have to be any difference.