[mythtv] [PATCH] Clogged filters
Daniel Kristjansson
danielk at cat.nyu.edu
Tue May 17 02:02:18 UTC 2005
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
More information about the mythtv-dev
mailing list