SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)

Nicolas Chauvet kwizart at gmail.com
Tue Jul 26 14:28:20 CEST 2016


2016-07-25 4:36 GMT+02:00 Sérgio Basto <sergio at serjux.com>:
> On Seg, 2016-07-25 at 04:02 +0200, Kevin Kofler wrote:
>> So for those stuck with such an old machine, it
>> is better to have a library that works (slowly) than one that just
>> crashes
>> with a SIGILL (illegal instruction).
>
> I think x264 , detects if have the cpu instructions and if not, have
> one fall back code, don't crash.
Okay to put an end to this thread, here are the tests:

# x264 -o out.mp4  BigBuckBunny_320x180.mp4
lavf [info]: 320x180p 1:1 @ 24/1 fps (vfr)
x264 [error]: your cpu does not support SSE1, but x264 was compiled with asm
x264 [error]: to run x264, recompile without asm (configure --disable-asm)
x264 [error]: x264_encoder_open failed
# mv /usr/lib/libx264.so.148 /usr/lib/sse2/
# mv /tmp/libx264.so.148 /usr/lib/
# ldconfig
# x264 -o out.mp4  BigBuckBunny_320x180.mp4
lavf [info]: 320x180p 1:1 @ 24/1 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: none!
x264 [info]: profile High, level 1.2
x264 [info]: frame I:5     Avg QP:17.11  size: 13610

This was tested on KVM guest with pentium 2 cpu emulated. Here are the
relevant cpuinfo flags there:
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr eagerfpu x2apic hypervisor vmmcall
(no mmx, or sse1/2 here).

Actually, I've tested on pentium3 which has sse1 but not sse2 and the
asm version worked there, so the runtime cpu detection work starting
with sse1, but not sse2.

The last cpuinfo case which is relevant to the thread is either this
work on AMD geode (probably one of the last produced 32bit only x86
cpu)
As seen here the result might be random:
http://wiki.laptop.org/go/Geode_instruction_set#supported_SSE1, but
sse is unlikely to be advertised by cpuinfo
This last is specially relevant for the OLPC project.


At the end, I think it's urgent not to move anything already working
fine in legacy architecture.

Thx


-- 
-

Nicolas (kwizart)


More information about the rpmfusion-developers mailing list