#19314 closed defect (fixed)
ffmpeg: enable mmx optimizations by default
Reported by: | dbevans (David B. Evans) | Owned by: | dbevans (David B. Evans) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.7.1 |
Keywords: | mmx Intel | Cc: | ryandesign (Ryan Carsten Schmidt) |
Port: | ffmpeg |
Description (last modified by dbevans (David B. Evans))
Based on recent reports the latest version of ffmpeg +mmx builds properly on Intel platforms (#19293).
XCode 3.1.2 or better is required on Leopard.
The attached proposed patch enables auto configuration of mmx optimizations as the default and checks for the proper XCode version on Leopard.
A no_mmx variant is included to disable these optimizations if desired.
Please respond if you have any concerns with this patch based on test results on Intel platforms.
Attachments (1)
Change History (10)
Changed 16 years ago by dbevans (David B. Evans)
Attachment: | patch-ffmpeg.diff added |
---|
comment:1 follow-up: 2 Changed 16 years ago by dbevans (David B. Evans)
Description: | modified (diff) |
---|---|
Status: | new → assigned |
comment:2 Changed 16 years ago by acho@…
This has been working for a while with the new xcode, but I was asked not to make it default until the next major OS release which includes the required gcc functionality. Thus a fresh install from an OS 10.5 with xcode from the OS disk will install ffmpeg with the default settings. It's been about 8 months since then, so the policy may have changed.
comment:3 follow-up: 4 Changed 16 years ago by dbevans (David B. Evans)
Since then the bug in XCode 3.0 has hit a number of other ports as well (x264 for instance) and it has been a fairly widely reported ticket item. Basically anything that uses assembly language inline.
Recent practice (see ryandesign's graphviz from which I cribbed the XCode check) is to check for the existence of the correct XCode version which helps to point people in the correct direction.
I don't see any benefit to wait further now since the issue already hit a number of other ports requiring people to upgrade to 3.1.2 but perhaps one or more of the MP managers would care to comment on the existence of any policy here.
I assume you concur that the problem is fixed given the correct version of XCode?
Thanks for your input.
comment:4 Changed 16 years ago by acho@…
I see what you mean. Actually, XCode 3.1 is the minimum to get ffmpeg working properly in Leopard with mmx and without cavs. I will test if cavs can be built with XCode 3.1.2 later today.
comment:5 Changed 16 years ago by acho@…
Correction, XCode 3.1 is the minimum to build with mmx; cavs did not fail to build after applying the patch.
comment:6 Changed 16 years ago by dbevans (David B. Evans)
Yes, I agree. I was just trying to get people to upgrade to the latest on general principal and you caught me! ;-)
In addition are these issues which I previously glossed over
- technically --disable-mmx only addresses a subset of Intel-like optimizations. The full set of configure options are
--disable-amd3dnow disable 3DNow! optimizations --disable-amd3dnowext disable 3DNow! extended optimizations --disable-mmx disable MMX optimizations --disable-mmx2 disable MMX2 optimizations --disable-sse disable SSE optimizations --disable-ssse3 disable SSSE3 optimizations
- the --disable-mmx configure option for ffmpeg is not completely effective in the current release 0.5 or on svn trunk (ffmpeg-devel.) The ifdef logic in libswscale/rgb2rgb.c keys on the definition of ARCH_X86 only and ignores and even overwrites HAVE_MMX, HAVE_MMX2, etc that result from the configure options. The resulting behavior is to compile separate versions of the accelerated functions for each possible combination of acceleration options. The correct optimization function is then selected based on a check at run time. Thus, at least in this one instance, there is no protection from the XCode 3.0 gcc compilation bug.
comment:7 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
MacPorts is documented to require Xcode 3.1 on Leopard. Use of Xcode 3.0 is unsupported. MacPorts base should fail to run if 3.0 is found. But, it does not do this yet. See #12794. Therefore, any port that actually requires Xcode 3.1 should add a check for it.
comment:8 Changed 16 years ago by dbevans (David B. Evans)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Proposed patch for Portfile