[FFmpeg-soc] [PATCH] 4/4 Split sws_getContext_altivec_alloc_context from sws_getContext

Michael Niedermayer michaelni at gmx.at
Sun Jun 15 02:41:31 CEST 2008


On Sun, Jun 15, 2008 at 01:55:57AM +0200, Luca Barbato wrote:
> Keiji Costantini wrote:
> > Luca Barbato ha scritto:
> >> Michael Niedermayer wrote:
> >>> On Wed, Jun 11, 2008 at 02:36:08AM +0200, Keiji Costantini wrote:
> >>>> -                p[j] = c->vLumFilter[i];
> >>>> -                p[j] = c->vChrFilter[i];
> >>> Whichever way this is done and whereever, it should be done at the
> >>> same place where lum/chrMmxFilter is initialized.
> >>> And of course both altivec & mmx should use the same array for the same data.
> >>>
> >>> But looking again it seems these arrays are practically unused and the
> >>> code using it looks like it shouldnt use them in the first place.
> >>>
> >>> So, correct cleanup seems to be to remove vCCoeffsBank and vYCoeffsBank.
> >> The *Banks are just a copy from aligned memory to another, so just using 
> >> the vLumFilter and vChrFilter directly won't cause problems.
> >>
> >> lu
> >>
> > extract from code:
> > 
> >      for (i=0;i<c->vLumFilterSize*c->dstH;i++) {
> >          int j;
> >          short *p = (short *)&c->vYCoeffsBank[i];
> >          for (j=0;j<8;j++)
> >              p[j] = c->vLumFilter[i];
> >      }
> > 
> > I see *Banks are *filters copied 8 times each...
> 
> I'm an idiot =P

At least i now know why i didnt understand your earlier reply :)


> 
> Well they could go away adding 2 vec_splats, but I'm pretty sure it 
> would slow things down. I'd consider this later -_-

I wouldnt be so sure that the splats are slower than the cache trashing the
array causes.
Also if done properly (like in the mmx code) then there are rather few splats.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20080615/0937e4eb/attachment.pgp>


More information about the FFmpeg-soc mailing list