[Ffmpeg-devel] [PATCH] h264 - loopify some get_cabac calls

[Guillaume Poirier]

Hey,

Alexander Strange a ?crit :
> This changes two series of straight-line get_cabac calls to loops.
>
> Before (skips are intentional):
> 45552 dezicycles in decode_mb_cabac, 8188 runs, 4 skips
> 39043 dezicycles in decode_mb_cabac, 13456 runs, 2928 skips
> 34729 dezicycles in decode_mb_cabac, 23559 runs, 9209 skips
> 32233 dezicycles in decode_mb_cabac, 44016 runs, 21520 skips
> 31117 dezicycles in decode_mb_cabac, 86431 runs, 44641 skips
> 30542 dezicycles in decode_mb_cabac, 171150 runs, 90994 skips
> 30203 dezicycles in decode_mb_cabac, 339742 runs, 184546 skips
> 30131 dezicycles in decode_mb_cabac, 710510 runs, 338066 skips
> 33107 dezicycles in decode_mb_cabac, 1411827 runs, 685325 skips
> 34922 dezicycles in decode_mb_cabac, 2822050 runs, 1372254 skips
>
> After:
> 45467 dezicycles in decode_mb_cabac, 8188 runs, 4 skips
> 38793 dezicycles in decode_mb_cabac, 13453 runs, 2931 skips
> 34406 dezicycles in decode_mb_cabac, 23555 runs, 9213 skips
> 31879 dezicycles in decode_mb_cabac, 44011 runs, 21525 skips
> 30729 dezicycles in decode_mb_cabac, 86434 runs, 44638 skips
> 30168 dezicycles in decode_mb_cabac, 171152 runs, 90992 skips
> 29826 dezicycles in decode_mb_cabac, 339746 runs, 184542 skips
> 29746 dezicycles in decode_mb_cabac, 710509 runs, 338067 skips
> 32694 dezicycles in decode_mb_cabac, 1411793 runs, 685359 skips
> 34513 dezicycles in decode_mb_cabac, 2822036 runs, 1372268 skips
>
> Not a big win, but there is a definite one.
> Since get_cabac is in asm, there's obviously some load/store hoisting 
> opportunities that aren't being taken. Not much to do about it though.

Wonderful!


>
> BTW, I haven't abandoned those other two patches yet, but haven't got 
> them quite as good on x86 as they should be.
> There's some more AltiVec code here we'll probably send soon: 
> http://trac.perian.org/ticket/113
I had a quick look at 
http://trac.perian.org/attachment/ticket/113/altivec_lum.3.diff

Even though I imagine this patch isn't yet ready to be submitted, I'd 
like to ask if the in your opinion, transpose routines can make do 
without accessing memory (do it all in registers).

Also more cycles could be saved if you take advantage of some known 
alignments (8-bytes aligned load/store can be made faster than a generic 
unaligned memory access)....

I do realize that this patch isn't meant for submission yet, I just 
wanted to give some kind of feedback.


Guillaume