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 19 09:35:46 CEST 2016


2016-07-19 2:55 GMT+02:00  <dominik at 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 at serjux.com> 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)


More information about the rpmfusion-developers mailing list