1 |
Frank Peters posted on Wed, 11 Mar 2015 00:23:03 -0400 as excerpted: |
2 |
|
3 |
> On Wed, 11 Mar 2015 03:25:24 +0000 (UTC) |
4 |
> Duncan <1i5t5.duncan@×××.net> wrote: |
5 |
> |
6 |
> |
7 |
>> Meanwhile, the 19 new MMX instructions were a subset of Intel's SSE |
8 |
>> (v1) |
9 |
>> instruction set. This SSE subset of 19 instructions is apparently what |
10 |
>> mmxext actually refers to. Thus, anything with sse in the cpuflags by |
11 |
>> definition has mmxext as well. |
12 |
>> |
13 |
>> |
14 |
> These flags have to be maintained for backwards compatibility, |
15 |
> I suppose, even though mmxext no longer makes sense on newer processors. |
16 |
> |
17 |
> Also, why the need to even specify the string of "sse sse2 sse3 sse4_1 |
18 |
> sse4_2 ssse3?" Each successive SSEX includes all previous instructions |
19 |
> so only the highest "X" for a given processor would be appropriate. |
20 |
|
21 |
I believe you're correct in general, in terms of keeping the strings |
22 |
around for backward compatibility. |
23 |
|
24 |
Tho I'm not sure you're /entirely/ correct on each sse generation exactly |
25 |
supersetting the previous. In particular, I believe there's some set- |
26 |
exclusions in the sse4 and ssse3 areas on specific CPUs. Additionally, |
27 |
there's cases where particular cpu's technically implement the code, but |
28 |
where those implementations aren't well optimized, such that if one cares |
29 |
enough to do the research or to actually do profiled optimization |
30 |
testing, certain instructions won't be used as they're actually slower |
31 |
than the alternatives. If a package uses these instructions, then, |
32 |
disabling the specific cpuflag for it when building that package can be a |
33 |
viable option, even with later cpuflags enabled. Were cpuflags always |
34 |
treated as supersets of the previous, that level of previous cpuflag |
35 |
disabling wouldn't be possible. |
36 |
|
37 |
|
38 |
Meanwhole, concerning mmxext specifically... |
39 |
|
40 |
I believe the distinction with mmxext is that (as I mentioned in the |
41 |
previous message) it never actually had an official name on its own. AMD |
42 |
blurred the lines both on what it included and on the name itself, and |
43 |
Intel apparently never adopted it in the first place, moving directly |
44 |
from mmx to sse. And since sse WAS an official and widely adopted name |
45 |
and included mmxext, mmxext basically got dropped by the wayside... |
46 |
except for the fringe "extreme technophile" class that builds from |
47 |
sources, who by definition are supposed to either know or be able to |
48 |
lookup this sort of thing in short order. |
49 |
|
50 |
IOW, basically, nobody else really cares. The masses get pre-built |
51 |
binaries that either process things efficiently (using the appropriate |
52 |
instructions but the masses don't know or care about that) or not, so |
53 |
they don't care. And most of the developer masses don't care either, |
54 |
since it never applied to Intel at all. Only a very few developers who |
55 |
happened to have AMD machines in the slot between mmx only and full sse, |
56 |
and knew they could make stuff like media encoding go faster with |
57 |
appropriate hand-coded assembly using these instructions, thus having |
58 |
that itch to scratch, and as a consequence, the very few gentooers and |
59 |
others building from sources the apps these developers created, had real |
60 |
reason to care. |
61 |
|
62 |
Meanwhile, arguably, since sse is known to superset mmxext, the gentoo |
63 |
ffmpeg maintainer got this wrong, and instead of setting up the required- |
64 |
use like that, he should have simply auto-enabled mmxext if sse was |
65 |
enabled. I imagine I might have coded it up like that, anyway, such that |
66 |
the few people only having mmxext could enable it, while the others could |
67 |
enable sse and not have to futz around with the mmxext corner case at all. |
68 |
|
69 |
If one cared enough about it, I suppose one could file a bug to that |
70 |
effect. However, now that the existing implementation is there and |
71 |
configured correctly works, I don't know that it's worth bothering with. |
72 |
And the maintainer may likewise consider it not worth his time... |
73 |
|
74 |
-- |
75 |
Duncan - List replies preferred. No HTML msgs. |
76 |
"Every nonfree program has a lord, a master -- |
77 |
and if you use the program, he is your master." Richard Stallman |