Closed eblanca closed 4 years ago
-mavx2 means anyone with CPU that doesn't have AVX2 instructions will not be able to use the plugin. I will separate the different routines (like I did with TMM2) so AVX2 will not be requirement and opt parameter will be kept. Btw here there is an example of such CMake.
-mavx2 means anyone with CPU that doesn't have AVX2 instructions will not be able to use the plugin.
~Well no, that option just means g++ will generate AVX2 instructions when compiling some intrinsics.~
I think the code is well protected using macro __AVX__
and first of all into
https://github.com/Asd-g/yadifmod2/blob/2c4f2146975eae83fc17749e40c1a02a2a06020d/avisynth/src/yadifmod2.cpp#L215
the detection routine queries avisynth+ engine and goes on using AVX2 only where the detection succeeds. So, where AVX2 instructions are not detected, they will not be used.
Then, the concern may be feeding the option -mavx2 to g++ and receive an error due to an old compiler, but I see that option is already present into g++ 4.8.x release (around 2013), so it should be quite reasonable assuming any recent systems have a well featured gnu compiler.
I was standing in the wrong assumption. From the gcc manual:
GCC depresses SSEx instructions when -mavx is used. Instead, it
generates new AVX instructions or AVX equivalence for all SSEx
instructions when needed.
This means also SSEx intrinsics may end generating AVX instructions and crash the filter when run on an old cpu.
Now for the different routines different arch targets could be set.
I applied minor modifications in order to have yadifmod built as native lib on my linux x64 box. It is now running smooth as libyadifmod2.so givin' bit identical deinterlacing result - using any arch. Please note I removed statement https://github.com/Asd-g/yadifmod2/blob/2c4f2146975eae83fc17749e40c1a02a2a06020d/avisynth/src/yadifmod2.cpp#L283 as a fix mainly because it makes an assertion fail when built with g++ (AsInt called with no parameter). Further, readme says any value is accepted :-)