[FFmpeg-devel] [PATCH] Assign unique values to AV_CPU_FLAG_IWMMXT and AV_CPU_FLAG_ALTIVEC.

[Michael Niedermayer]

On Wed, Sep 08, 2010 at 01:44:30PM +0200, Janne Grunau wrote:
> On Wed, Sep 08, 2010 at 12:11:15PM +0200, Michael Niedermayer wrote:
> > On Wed, Sep 08, 2010 at 11:56:30AM +0200, Stefano Sabatini wrote:
> > > On date Sunday 2010-09-05 21:51:57 -0400, Ronald S. Bultje encoded:
> > > > 
> > > > I don't think this is a good idea, as previously said.
> > > > 
> > > > Every use of AV_CPU_FLAG_ALTIVEC currently is, and should be, under
> > > > HAVE_ALTIVEC and every use of AV_CPU_FLAG_SSE*/MMX*/3DNOW/etc should
> > > > be under HAVE_MMX, since these are all exclusive. A real-life CPU will
> > > > never support both altivec and SSSE3.
> > > > 
> > > > Since this doesn't solve a problem and actually adds a problem of
> > > > having only 32 flags for all CPU extensions out there on all archs,
> > > > which is rather limiting given the amount of new extensions Intel and
> > > > Arm come up with every few months. Therefore, I'd rather not see this
> > > > committed.
> > > 
> > > I don't have a strong opinion so I can easily drop this patch, but
> > > having the same flag with different meanings is intrinsically messy,
> > 
> > > and I remember an user complaining about that for some reason.
> > 
> > thats a bad argument independant of what is discussed
> > or in other words if you dont remember the reasoning it really isnt helpfull
> 
> The "user" was me, I've started using mm_support() for real runtime CPU
> dectection in swscale under CONFIG_RUNTIME_CPUDETECT. The obvious
> implementation:
> 
> if (mm_flags && FF_MM_MMX)
> 	cpuflags |= SWS_CPU_CAPS_MMX;
> if (mm_flags && FF_MM_ALTIVEC)
> 	cpuflags |= SWS_CPU_CAPS_ALTIVEC;
> 
> had strange results since SWS_CPU_CAPS_MMX != SWS_CPU_CAPS_ALTIVEC.
> Easily solveable with adding HAVE_(MMX|ALTIVEC) && to the ifs.
> 
> I think not reusing flags is cleaner but I don't really care.

this kind of problems can be avoided by making the flags 0 or undefined
on platforms where such extension is impossible

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

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- 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/20100908/5ba9d5d7/attachment.pgp>