[FFmpeg-devel] Does i686 have MMX?

Michael Niedermayer michaelni
Thu Aug 26 22:12:29 CEST 2010


On Thu, Aug 26, 2010 at 02:29:25PM -0400, Jason Garrett-Glaser wrote:
> 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".  --cpu=i686 is
> widely used in order to enable CMOV on normal builds.  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.
> 
> 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.

i dont mind in principle but this is pushing problems around
that is we would have to find solutiion to all issues that global var caused
dont ask me about it though i wasnt working on this ...
thus the practicality of this depends on other solutions being found where
needed and these other solutions being not worse


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

this is a possible solution as well


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

> 4.  Modify the emms change to take an argument instead of using a
> global variable.

this could become a bit ugly


> 
> Benefits: no behavioral changes, everything works just as before,
> except with no global.
> Possible problems: ugly.
>


> I will revert any patch that silently disables mmx on any CPU.

i think that wont help peoplr reaching a consensus

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100826/957b1311/attachment.pgp>



More information about the ffmpeg-devel mailing list