[FFmpeg-devel] Does i686 have MMX?

[Måns Rullgård]

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.

> 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.

> 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.

-- 
M?ns Rullg?rd
mans at mansr.com