1/3) Why not have mm_support() return MM_ALTIVEC if altivec is available?1) A lot of the filters have common stuff that should be abstracted (e.g. mm_support() or emms() for non-Intel compilation, content of .pro files are nearly identical) 2) Several dummy functions are needlessly defined for non-MMX 3) Altivec accelleration is not determined at run time 4) Using i386 instead of MMX.
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.
2) ok, get rid of these.
4) Can't do it. i386 != MMX. MMX is defined when the processor is any
MMX supporting processor, while i386 is defined when the processor is a
IA32 processor supporting MMX. The problem is that the instruction
mnemonics have different meanings on a x86-64, popl still pops a long
off the stack, but now a long is 64 bits not 32 bits, so it won't fit in
eax... Anyway, some algorithms have been ported to work on a x86-64, and
others haven't so we need the two defines.
Aah. OK, that makes (a bit more) sense now. Maybe having MMX and MMX64 would be clearer?
Better names (or other criticism) gladly accepted/debated, otherwise I will commit in a few days?Thanks for not committing right away, I already did the i386 -> MMX change a few weeks ago, and had to revert...
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 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?
--
Nigel Pearson, [EMAIL PROTECTED]| "Let's see how Spike is going"
Telstra BI&D, Sydney, Australia | ...
Office: 8255 4222 Fax: 8255 3153 |"I'd like to keep Spike as my pet."
Mobile: 0408 664435 Home: 9792 6998 | Illyria - Angel
_______________________________________________ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
