On 19 Jul 2016, at 02:12, Sérgio Basto <sergio(a)serjux.com>
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> 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