On Tue, 2005-05-17 at 10:09 +1000, Nigel Pearson wrote: > > This is already implemented in libs/libavcodec/ppc/dsputil_ppc.c > That is the plan - patched linearblend/filter_linearblend.c > (the only filter with Altivec acceleration) uses libavcodec's. cool.
> > 4) Can't do it. i386 != MMX. MMX is defined when the processor is any > Aah. OK, that makes (a bit more) sense now. > Maybe having MMX and MMX64 would be clearer? Maybe keeping MMX but changing i386 to MMX32 would be clearer. My only reservation is that much of this code is borrowed and this might complicate syncing with the original code. But I think filter_linearblend.c is the only place where i386 remains. Perhaps we can just port that ourselves? > I had initially changed all the MMXs to i386, > and the HAVE_ALTIVECs to ARCH_POWERPC, but then had > to think about what MMX or HAVE_ALTIVEC really meant. In theory these just mean our toolchain supports the constructs, but in a few places we don't do runtime detection, so in practice it means we use the accelerated routines if we compile with them. > In a perfect world, we might have USE_MMX, USE_MMX64, > and USE_ALTIVEC, which configure would disable if the > build was not that architecture, or the compiler was not > capable of dealing with those extensions. But backwards > compatibility means we are stuck with the current symbols? Well in avlib we are stuck with the existing defines (for syncing reasons), but in MythTV proper we can change things. Nothing prevents you from using runtime detection in PowerPC world while we lag behind in x86 world. I'll look at filter_linearblend.c tomorrow night, I didn't realize we were down to just one function until I grepped the code tonight. -- Daniel
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
