[FFmpeg-devel] Does i686 have MMX?

[Alex Converse]

2010/8/26 M?ns Rullg?rd <mans at mansr.com>:
> Jason Garrett-Glaser <darkshikari at gmail.com> writes:
>
>> The issue is simple:
>>
>> 1. ?People use --cpu on x86 to mean "it should run on at least this
>> CPU, and contain optimizations for all better CPUs".
>
> Are you aware of the contradiction in that statement?
>

please elaborate

>> --cpu=i686 is widely used in order to enable CMOV on normal builds.
>
> Is it? ?I doubt most people cargo-culting configure lines have so much
> as heard of cmov.
>

Maybe not but they do generally know that is runs on something of
1997-ish vintage but autodetects optimizations

>> Even if this is wrong, this is what people do. ?We cannot silently
>> go and break what everyone currently does, it's just not reasonable.
>
> When people have inconsistent expectations, behaving consistently
> becomes very hard. ?If we do what is right, people will eventually
> learn (or copy from someone who has).
>
>> 2. ?This patch SILENTLY DISABLES MMX on almost all ffmpeg builds in
>> the world. ?This is bad. ?I don't care if it's right, it's bad.
>>
>> 3. ?MMX should NEVER EVER be disabled unless --disable-mmx is passed.
>> End of story.
>>
>> Possible solutions:
>>
>> 1. ?Revert the emms change.
>>
>> 2. ?By policy, make ffmpeg require MMX to run by default. ?Add a
>> runtime check, just in case. ?Any --cpu that doesn't support MMX will
>> error out unless the user specifies --disable-mmx too.
>>
>> Benefits: --cpu still makes logical sense, keeps the emms change, and
>> we can enable CMOV by default too (i.e. if --cpu isn't set).
>> Possible problems: this still breaks everyone's build scripts, but at
>> least it'll break them loudly, so people will fix them.
>
> This option is the least logically inconsistent of those presented.
>
>> 3. ?By policy, make ffmpeg require MMX to run by default. ?Add a
>> runtime check, just in case, telling the user to recompile without MMX
>> if they're on an unsupported CPU. ?Don't check the user's --cpu option
>> when it comes to validating this. ?This is what x264 does.
>>
>> Benefits: simple, doesn't break build scripts, and x264 showed that
>> it worked. ?Possible problems: --cpu doesn't do quite what it
>> implies -- adds runtime failure instead of compile-time.
>
> There is no obvious place to perform a runtime check guaranteed to
> always be executed. ?Besides, failing at runtime will only make users
> angry.
>

agreed

>> 4. ?Modify the emms change to take an argument instead of using a
>> global variable.
>>
>> Benefits: no behavioral changes, everything works just as before,
>> except with no global.
>> Possible problems: ugly.
>
> Most places calling emms() have no value at hand to pass as an argument.
>

most places calling emms_c() don't actually need to.

The others can cache a mm_support as a local or in the context.