On 19 Jul 2016, at 02:12, Sérgio Basto <sergio(a)serjux.com&gt; wrote: On Ter, 2016-07-19 at 02:55 +0200, dominik(a)greysector.net wrote: > Hello, Sérgio. > > On Tuesday, 19 July 2016 at 02:35, RPM Fusion Bugzilla wrote: >> >> https://bugzilla.rpmfusion.org/show_bug.cgi?id=3975 >> >> --- Comment #4 from Sérgio Basto <sergio(a)serjux.com&gt; 2016-07-19 >> 02:35:19 CEST --- >> (In reply to comment #3) >>> >>> I'll take a look at this. Could you try running execstack -c on >>> the installed >>> library in the meantime? >> Be my guest , in meantime I read your thread on packaging Mailing >> list about >> sse3 , I'd like understand if we need 2 builds for i686 ... one >> with sse2 other >> without it, can you give us your opinion ? > The only real concern here are applications linked against libx264, > which someone might want to run on low-end hardware, because I don't > think anyone would want to encode anything to H.264 on non-SSE2 > capable > CPU (i.e. Pentium 3 or Athlon XP and older). Considering last non- > SSE2 > CPUs went out of production about 8 years ago, I think it's fairly > safe > to assume that the impact of doing SSE2-only builds would be > negligible, > if any. From x264.spec we can read "#i686 is disabled on purpose - re-enabled with sse2 build" It is safe to say enable sse2 build is enable asm code ? if yes %ifarch i686 we can/should build with enable asm code ? and only one time isn't it ? I tried that, but kwizart didn't agree ...

On Tuesday, 19 July 2016 at 10:31, Simon Farnsworth wrote: > > > On 19 Jul 2016, at 02:12, Sérgio Basto <sergio(a)serjux.com&gt; wrote: > > > > On Ter, 2016-07-19 at 02:55 +0200, dominik(a)greysector.net wrote: > >> Hello, Sérgio. > >> > >> On Tuesday, 19 July 2016 at 02:35, RPM Fusion Bugzilla wrote: > >>> > >>> https://bugzilla.rpmfusion.org/show_bug.cgi?id=3975 > >>> > >>> --- Comment #4 from Sérgio Basto <sergio(a)serjux.com&gt; 2016-07-19 > >>> 02:35:19 CEST --- > >>> (In reply to comment #3) > >>>> > >>>> I'll take a look at this. Could you try running execstack -c on > >>>> the installed > >>>> library in the meantime? > >>> Be my guest , in meantime I read your thread on packaging Mailing > >>> list about > >>> sse3 , I'd like understand if we need 2 builds for i686 ... one > >>> with sse2 other > >>> without it, can you give us your opinion ? > >> The only real concern here are applications linked against libx264, > >> which someone might want to run on low-end hardware, because I don't > >> think anyone would want to encode anything to H.264 on non-SSE2 > >> capable > >> CPU (i.e. Pentium 3 or Athlon XP and older). Considering last non- > >> SSE2 > >> CPUs went out of production about 8 years ago, I think it's fairly > >> safe > >> to assume that the impact of doing SSE2-only builds would be > >> negligible, > >> if any. > > > > From x264.spec we can read "#i686 is disabled on purpose - re-enabled > > with sse2 build" > > > > It is safe to say enable sse2 build is enable asm code ? if yes %ifarch > > i686 we can/should build with enable asm code ? and only one time > > isn't it ? I tried that, but kwizart didn't agree ... > > It may not be worth the effort (as there's upstream effort here, not just > packaging, if I understand correctly), but https://lwn.net/Articles/691932/ > documents GCC 6 function multi-versioning, which enables you to build both > SSE2 and non-SSE versions of a given functions, and have GCC generate code > to choose the right version at run time - as it's part of the compiler, the > optimiser should also be aware, and able to avoid dispatch code when calling > from the SSE2 version to another SSE2 function. It's definitely not worth the effort. x264 upstream considers non-SSE2 x86 CPUs obsolete.

Hello, Sérgio. On Tuesday, 19 July 2016 at 02:35, RPM Fusion Bugzilla wrote: > https://bugzilla.rpmfusion.org/show_bug.cgi?id=3975 > > --- Comment #4 from Sérgio Basto <sergio(a)serjux.com&gt; 2016-07-19 02:35:19 CEST --- > (In reply to comment #3) > > I'll take a look at this. Could you try running execstack -c on the installed > > library in the meantime? > > Be my guest , in meantime I read your thread on packaging Mailing list about > sse3 , I'd like understand if we need 2 builds for i686 ... one with sse2 other > without it, can you give us your opinion ? The only real concern here are applications linked against libx264, which someone might want to run on low-end hardware, because I don't think anyone would want to encode anything to H.264 on non-SSE2 capable CPU (i.e. Pentium 3 or Athlon XP and older). Considering last non-SSE2 CPUs went out of production about 8 years ago, I think it's fairly safe to assume that the impact of doing SSE2-only builds would be negligible, if any.

2016-07-19 2:55 GMT+02:00  <dominik@greysector.net>: > > Hello, Sérgio. > > On Tuesday, 19 July 2016 at 02:35, RPM Fusion Bugzilla wrote: > > > > https://bugzilla.rpmfusion.org/show_bug.cgi?id=3975 > > > > --- Comment #4 from Sérgio Basto <sergio(a)serjux.com&gt; 2016-07-19 > > 02:35:19 CEST --- > > (In reply to comment #3) > > > > > > I'll take a look at this. Could you try running execstack -c on > > > the installed > > > library in the meantime? > > Be my guest , in  meantime I read your thread on packaging > > Mailing list about > > sse3 , I'd like understand if we need 2 builds for i686 ... one > > with sse2 other > > without it, can you give us your opinion ? > The only real concern here are applications linked against libx264, > which someone might want to run on low-end hardware, because I > don't > think anyone would want to encode anything to H.264 on non-SSE2 > capable > CPU (i.e. Pentium 3 or Athlon XP and older). Considering last non- > SSE2 > CPUs went out of production about 8 years ago, I think it's fairly > safe > to assume that the impact of doing SSE2-only builds would be > negligible, > if any. I'm okay to have a SSE2 only build for single binaries such as pcsx2 for the following reasons: - pcsx2 requires more CPU resources than barely capable sse2 CPU anyway. - Using sse2 will allow older but sse2 capable CPU to run. - Runtime test has to be made to avoid crash and notify user if the CPU don't have sse2. But for libraries it's not possible to assume a given usage and ensure users notification. I expect you can have webcam app to encode to h264 low profile just fine using x264 even on non-sse2 capable cpu. It's expected not to crash here.

So I don't understand why this discussion raised up again, but I'd like not to more anything in i686 that will made some corner case users to crash.

On Ter, 2016-07-19 at 09:35 +0200, Nicolas Chauvet wrote: > 2016-07-19 2:55 GMT+02:00 <dominik(a)greysector.net&gt;: > > > > Hello, Sérgio. > > > > On Tuesday, 19 July 2016 at 02:35, RPM Fusion Bugzilla wrote: > > > > > > https://bugzilla.rpmfusion.org/show_bug.cgi?id=3975 > > > > > > --- Comment #4 from Sérgio Basto <sergio(a)serjux.com&gt; 2016-07-19 > > > 02:35:19 CEST --- > > > (In reply to comment #3) > > > > > > > > I'll take a look at this. Could you try running execstack -c on > > > > the installed > > > > library in the meantime? > > > Be my guest , in meantime I read your thread on packaging > > > Mailing list about > > > sse3 , I'd like understand if we need 2 builds for i686 ... one > > > with sse2 other > > > without it, can you give us your opinion ? > > The only real concern here are applications linked against libx264, > > which someone might want to run on low-end hardware, because I > > don't > > think anyone would want to encode anything to H.264 on non-SSE2 > > capable > > CPU (i.e. Pentium 3 or Athlon XP and older). Considering last non- > > SSE2 > > CPUs went out of production about 8 years ago, I think it's fairly > > safe > > to assume that the impact of doing SSE2-only builds would be > > negligible, > > if any. > I'm okay to have a SSE2 only build for single binaries such as pcsx2 > for the following reasons: > - pcsx2 requires more CPU resources than barely capable sse2 CPU > anyway. > - Using sse2 will allow older but sse2 capable CPU to run. > - Runtime test has to be made to avoid crash and notify user if the > CPU don't have sse2. > > But for libraries it's not possible to assume a given usage and > ensure > users notification. > I expect you can have webcam app to encode to h264 low profile just > fine using x264 even on non-sse2 capable cpu. > It's expected not to crash here. As I state before, I think, even in this case, x264 asm code, have a fall back when don't have sse2 instructions and don't crash, that is my point, but just testing to be sure. I don't see any hardware here to test it, even though it is a big challenge try install Fedora 24 in a non-sse2 capable cpu .

On 07/19/2016 02:26 PM, Nicolas Chauvet wrote: > > > > > As I state before, I think, even in this case, x264 asm code, > > have a > > fall back when don't have sse2 instructions and don't crash, that > > is my > > point, but just testing to be sure. I don't see any hardware here > > to > > test it, even though it is a big challenge try install Fedora 24 > > in > > a non-sse2 capable cpu . Well, it's not easy to install F24, but it's doable. > > You could setup a x86 32bit virtual machine using KVM install > fedora, > then mask cpu, or use pentium 3 as a CPU for the guest vm and > reboot. I do have a PIII (w/o sse3) running F24.

Ralf

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).

2016-07-25 4:36 GMT+02:00 Sérgio Basto <sergio(a)serjux.com&gt;: > > 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

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(a)serjux.com&gt;: > > > > > > > > > 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 .