Re: Ffmpeg Emerge Problem

Frank Peters posted on Wed, 11 Mar 2015 00:23:03 -0400 as excerpted:

> On Wed, 11 Mar 2015 03:25:24 +0000 (UTC)
> Duncan <[email protected]> wrote:
> 
> 
>> Meanwhile, the 19 new MMX instructions were a subset of Intel's SSE
>> (v1)
>> instruction set.  This SSE subset of 19 instructions is apparently what
>> mmxext actually refers to.  Thus, anything with sse in the cpuflags by
>> definition has mmxext as well.
>> 
>> 
> These flags have to be maintained for backwards compatibility,
> I suppose, even though mmxext no longer makes sense on newer processors.
> 
> Also, why the need to even specify the string of "sse sse2 sse3 sse4_1
> sse4_2 ssse3?"  Each successive SSEX includes all previous instructions
> so only the highest "X" for a given processor would be appropriate.

I believe you're correct in general, in terms of keeping the strings 
around for backward compatibility.

Tho I'm not sure you're /entirely/ correct on each sse generation exactly 
supersetting the previous.  In particular, I believe there's some set-
exclusions in the sse4 and ssse3 areas on specific CPUs.  Additionally, 
there's cases where particular cpu's technically implement the code, but 
where those implementations aren't well optimized, such that if one cares 
enough to do the research or to actually do profiled optimization 
testing, certain instructions won't be used as they're actually slower 
than the alternatives.  If a package uses these instructions, then, 
disabling the specific cpuflag for it when building that package can be a 
viable option, even with later cpuflags enabled.  Were cpuflags always 
treated as supersets of the previous, that level of previous cpuflag 
disabling wouldn't be possible.


Meanwhole, concerning mmxext specifically...

I believe the distinction with mmxext is that (as I mentioned in the 
previous message) it never actually had an official name on its own.  AMD 
blurred the lines both on what it included and on the name itself, and 
Intel apparently never adopted it in the first place, moving directly 
from mmx to sse.  And since sse WAS an official and widely adopted name 
and included mmxext, mmxext basically got dropped by the wayside... 
except for the fringe "extreme technophile" class that builds from 
sources, who by definition are supposed to either know or be able to 
lookup this sort of thing in short order.

IOW, basically, nobody else really cares.  The masses get pre-built 
binaries that either process things efficiently (using the appropriate 
instructions but the masses don't know or care about that) or not, so 
they don't care.  And most of the developer masses don't care either, 
since it never applied to Intel at all.  Only a very few developers who 
happened to have AMD machines in the slot between mmx only and full sse, 
and knew they could make stuff like media encoding go faster with 
appropriate hand-coded assembly using these instructions, thus having 
that itch to scratch, and as a consequence, the very few gentooers and 
others building from sources the apps these developers created, had real 
reason to care.

Meanwhile, arguably, since sse is known to superset mmxext, the gentoo 
ffmpeg maintainer got this wrong, and instead of setting up the required-
use like that, he should have simply auto-enabled mmxext if sse was 
enabled.  I imagine I might have coded it up like that, anyway, such that 
the few people only having mmxext could enable it, while the others could 
enable sse and not have to futz around with the mmxext corner case at all.

If one cared enough about it, I suppose one could file a bug to that 
effect.  However, now that the existing implementation is there and 
configured correctly works, I don't know that it's worth bothering with.  
And the maintainer may likewise consider it not worth his time...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman