[MPlayer-dev-eng] [PATCH] altivec fixes, part 2: missing vec_splat
Alan Curry
pacman at TheWorld.com
Tue Feb 7 12:27:54 CET 2006
Diego Biurrun writes the following:
>
>Can you point me to some documentation about vec_splat? The best I
>could come up with was
>
>http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/index.jsp?topic=/com.ibm.xlf101l.doc/xlflr/vec_splat.htm
>
I've been working from this:
http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf
plus the notes in the gcc info manual.
However, after you asked me to elaborate the first time, I and found that the
AVV(16) == {16,0,0,0,...} is an undocumented difference between my compiler's
behavior and the specification. So I figure it might be a compiler bug;
someone with a newer gcc might not see the same behavior.
d = vec_splat(s,0) takes the 0'th (first) element of s and copies it into all
the elements of d, thus providing an easy way to convert {16,0,0,0,...} into
{16,16,16,16,...}
cvs log yuv2rgb_altivec.c reveals that vec_splat was added at the same time
the AVV() macro was introduced (AVV() covers a difference between compilers:
gcc uses parentheses around a vector literal, other compilers use braces). It
wasn't added everywhere though. Maybe there was a reason but I suspect it was
an accident. If the people mentioned in that cvs log entry are still
available, maybe they could elaborate further. It's been a while though:
----------------------------
revision 1.4
date: 2004/10/05 19:11:00; author: michael; state: Exp; lines: +231 -95
postproc/yuv2rgb_altivec.c compile fix
yuv2rgb_altivec_init_tables does initialize the SwsContext vectors.
missing vec_splat.
patch by (Luca Barbato <lu_zero at gentoo dot org>) and (Romain Dolbeau <dolbeau at irisa dot fr>)
----------------------------
Everything I know about altivec I learned while chasing down this bug.
(Also everything I know about YUV. It's been a long but rewarding chase)
Of the many bugs I'm submitting patches for, this is the one that, when
triggered, causes the most obvious symptom, since it causes 7 of every 8
pixels to be replaced with 0's! The other bugs I sort of stumbled on while I
was on the way to this one.
More information about the MPlayer-dev-eng
mailing list