[Ffmpeg-devel] [PATH] test if cpu supports CMOV

Guillaume POIRIER gpoirier
Fri Oct 13 17:53:13 CEST 2006


Hi,

Michael Niedermayer a ?crit :
> Hi
> 
> On Fri, Oct 13, 2006 at 05:35:13PM +0800, Zuxy Meng wrote:
>> Hi,
>>
>> 2006/10/13, Guillaume Poirier <gpoirier at mplayerhq.hu>:
>>> Hi,
>>> 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)
> 
> solution:
> 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
> code

Seconded.

Guillaume




More information about the ffmpeg-devel mailing list