[FFmpeg-devel] Does i686 have MMX?

[Alex Converse]

On Thu, Aug 26, 2010 at 2:58 PM, Jason Garrett-Glaser
<darkshikari at gmail.com> wrote:
> 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?
>>
>>> --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.
>>
>>> 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.
>
> Requiring an explicit --disable-mmx for CPUs without MMX is not
> logically inconsistent -- it's a tool to make it more difficult for
> users to stab themselves in the face.
>

Let's rewrite out external API in C#