Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
Sérgio Basto wrote: > 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 . And I disagree with that solution, because it is not compliant with the expected architecture support of the distribution. If you want to enable the ASM, you will need to patch it to fix it to properly runtime-detect also SSE 1 and MMX. Kevin Kofler
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
2016-07-28 7:29 GMT+02:00 Sérgio Basto : > 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 : >> > > >> > > >> > > 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)
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
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 : > > > > > > > > > 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 . > > > > Thx > > > > -- Sérgio M. B.
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
On Ter, 2016-07-26 at 14:28 +0200, Nicolas Chauvet wrote: > 2016-07-25 4:36 GMT+02:00 Sérgio Basto : > > > > 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 ... > Thx > > -- Sérgio M. B.
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
2016-07-25 4:36 GMT+02:00 Sérgio Basto : > 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)
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
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. -- Sérgio M. B.
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
domi...@greysector.net wrote: > 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. There is an expectation that Fedora packages run on any CPU supported by Fedora. For i686, that is currently any i686 CPU with cmov. You are not allowed to assume ANY vector instructions, not SSE2, not SSE (1), not even MMX. (It is of course fine to use all of these with appropriate runtime detection.) I think it is very reasonable to expect the same from RPM Fusion packages, considering that RPM Fusion's policy is normally to follow Fedora policies except for licensing stuff and kernel modules. This is all the more true for a library package, where the library can end up being used in many applications. Those applications will not necessarily want to encode H.264 in real-time, it can be perfectly acceptable for something like the ffmpeg command line to take longer than the video's playing length to encode it. 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 know some upstreams are uncooperative at this. Aggressive reverts of offending upstream patches are one solution, changing #ifdefs from something like: #ifdef __i686__ to something like: #if defined(__i686__) && defined(__SSE2__) are another. I did a combination of both to fix QtWebEngine: http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/tree/qtwebengine-opensource-src-5.7.0-no-sse2.patch (The Chromium packaging should also use such a patch, but currently doesn't. Send your complaints about that to spot. :-) ) Kevin Kofler
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
2016-07-19 13:36 GMT+02:00 Sérgio Basto : > On Ter, 2016-07-19 at 09:35 +0200, Nicolas Chauvet wrote: >> 2016-07-19 2:55 GMT+02:00 : >> > >> > 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 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 . 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. If the x264 works (not only not crash) then there is no reason not to enable asm by default there. -- - Nicolas (kwizart)
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
2016-07-19 13:36 GMT+02:00 Sérgio Basto : > On Ter, 2016-07-19 at 09:35 +0200, Nicolas Chauvet wrote: >> 2016-07-19 2:55 GMT+02:00 : >> > >> > 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 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 . > >> 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. > > Me, Dominik Mierzejewski, Simone Caronni at least have the same > opinion. you should accept the voting ... :) Please consider arguments over vote, if you can't discuss an issue before making a decision, this has nothing to do with democracy. -- - Nicolas (kwizart)
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
On Ter, 2016-07-19 at 09:35 +0200, Nicolas Chauvet wrote: > 2016-07-19 2:55 GMT+02:00 : > > > > 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 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 . > 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. Me, Dominik Mierzejewski, Simone Caronni at least have the same opinion. you should accept the voting ... :) Thanks, -- Sérgio M. B.
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
2016-07-19 12:37 GMT+02:00 Dominik 'Rathann' Mierzejewski : > On Tuesday, 19 July 2016 at 10:31, Simon Farnsworth wrote: >> >> > On 19 Jul 2016, at 02:12, Sérgio Basto wrote: >> > >> > On Ter, 2016-07-19 at 02:55 +0200, domi...@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 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. That can still be used for AVX and SSSE3, etc. (neon) As soon as the principle for runtime detection lands upstream, adding SSE2 shouldn't be a big effort. -- - Nicolas (kwizart)
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
2016-07-19 10:31 GMT+02:00 Simon Farnsworth : > >> On 19 Jul 2016, at 02:12, Sérgio Basto wrote: >> >> On Ter, 2016-07-19 at 02:55 +0200, domi...@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 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. Indeed, that's clearly the way to go for upstream, even if before that there is hwcaps -- - Nicolas (kwizart)
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
On Tuesday, 19 July 2016 at 09:35, Nicolas Chauvet wrote: > 2016-07-19 2:55 GMT+02:00 : > > 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 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. In principle, I agree, even though I doubt it's a real world issue. There's no reason not to build both with and without sse2 enabled, though. Regards, -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
On Tuesday, 19 July 2016 at 10:31, Simon Farnsworth wrote: > > > On 19 Jul 2016, at 02:12, Sérgio Basto wrote: > > > > On Ter, 2016-07-19 at 02:55 +0200, domi...@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 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. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
> On 19 Jul 2016, at 02:12, Sérgio Basto wrote: > > On Ter, 2016-07-19 at 02:55 +0200, domi...@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 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. -- Simon Farnsworth
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
2016-07-19 2:55 GMT+02:00 : > 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 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. -- - Nicolas (kwizart)
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
On Ter, 2016-07-19 at 02:55 +0200, domi...@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 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 ... > Regards, > Dominik -- Sérgio M. B.
SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
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 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. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
