[Ffmpeg-devel] [PATH] test if cpu supports CMOV
Fri Oct 13 17:53:13 CEST 2006
Michael Niedermayer a ?crit :
> On Fri, Oct 13, 2006 at 05:35:13PM +0800, Zuxy Meng wrote:
>> 2006/10/13, Guillaume Poirier <gpoirier at mplayerhq.hu>:
>>> The attached patch (hopefully) allows to test for the presence of CMOV
>>> instruction, introduced in _real_ i686 CPUs.
>>> It's needed for latest and greatest CABAC code, as some cpus that
>>> claim to be i686 do not support cmov (such as VIA C3).
>>> This patch creates #define HAVE_CMOV 1 for config.h and
>>> TARGET_CMOV=yes for config.mak.
>>> I don't know if the name is too wise, maybe it would be better to have
>>> HAVE_X86_CMOV to specify that were are talking about x86 in
>>> particular (other CPU support conditional move too, sadly, PPC doesn't).
> this will break runtime cpudetect (yeah i know my crap code already
> broke it but thats not supposed to stay that way in svn)
> 1. clean configure so that
> --cpu selects the minimum cpu required (-mcpu/-march)
> --tune selects the target cpu for which to tune but doent cause possibly
> unsupported instructions to be generated (-mtune)
> 2. set HAVE_CMOV depening on --cpu
Although I would have preferred if I wouldn't have had to write all what
you require to have a decent support of CMOV, since you have nailed us
so many times to get it, I'm gonna do what you suggest.
Take it as a reward for optimizing CABAC, which is quite an achievement
I must say. :o)
>> Why not detect it at run-time in cputest.c, just like what we've done
>> for 3DNow!, SSE, etc.?
> rejected, considering the small gain and huge increase in complexity
> (=duplicate half of h264.c in the object file and thats just what cabac
> would cause, there are a few more cmovs around IIRC)
> of course you can do the work benchmark it and submit a patch if you
> dissagree, ill apply it if its clean, doesnt unreasonable increase
> object or source size and theres no speed loss relative to the current
More information about the ffmpeg-devel