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]

2016-07-28 7:29 GMT+02:00 Sérgio Basto <sergio at serjux.com>:
> On Ter, 2016-07-26 at 16:54 +0100, Sérgio Basto wrote:
>> On Ter, 2016-07-26 at 14:28 +0200, Nicolas Chauvet wrote:
>> >
>> > 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.
>> yeah , so at least doesn't crash and I was right about x264 have
>> fallback code for pentium3 (so the runtime cpu detection work
>> starting
>> with sse1), which makes me think because of pentium2 we don't have
>> full
>> features ... , but OK, for now, makes sense disable asm on i686 ...
>> BTW and for 10b ? (compile with --bit-depth=10 ) make sense also make
>> 2
>> builds or can I enable asm there ? or just leave as is (one build
>> without asm).
>>
>> I also read yesterday, about http://emmabuntus.sourceforge.net/, This
>> distribution was originally designed to facilitate the reconditioning
>> of computers, given to humanitarian organizations ...
>>
>
> Thinking betterm since doesn't crash , and in pentium 2 we have a
> message to disable-asm , I think we should enable asm by default , and
> at most drop a note in wiki , that PII are not supported or something
> like that .

Binanary doesn't crash, but doesn't work either. now nothing prevent
another binary using the libx264 library directly to crash with
SIGILL.

For other libx264 with 10bit, I don't think it's relevant to also
build the non asm version since it will be used by compute intensive
video application ( and will be dlopened as isn't linked, so that's a
different story).

Thx




-- 
-

Nicolas (kwizart)