[XviD-devel] [CVS commit] Linux amd64 preliminary support
Edouard Gomez
ed.gomez at free.fr
Fri Jan 7 00:11:27 CET 2005
Guillaume POIRIER (guillaume.poirier at etudiant.univ-rennes1.fr) wrote:
> So here are the figures:
>
> Filters: -vf crop=688:448:18:60,pp=fd,scale=480:288
> Source: MPEG-2 (PAL DVD) 518,960 secs, 12975 frames
>
> XviD options:
> me_quality=6:chroma_me:chroma_opt:trellis:closed_gop:max_bframes=2:hq_ac:vhq=4:bvhq=1:autoaspect:psnr:bitrate=900
>
> Lavc options:
> vcodec=mpeg4:vmax_b_frames=1:mbd=2:v4mv:vqblur=0.37:vlelim=-4:vcelim=7:vqblur=0.37:vqcomp=0.65:lumi_mask=0.03:dark_mask=0.01:cmp=2:subcmp=2:precmp=2:dia=-1:trell:cbp:mv0:turbo:autoaspect:psnr:vbitrate=900
>
> On x86-64
> Pure C | XviD SIMD yasm | XviD Edouard SIMD | lavc + SIMD
> Pass 1: 37fps | 68fps | 78fps | 79fps
> Pass 2: 11fps | 30fps | 32fps | 30fps
>
> On IA-32
> Pure C | XviD SIMD yasm | XviD Edouard SIMD | lavc + SIMD
> Pass 1: 25fps | N/A | 80fps | 74fps
> Pass 2: 9fps | N/A | 31fps | 28fps
>
>
> The same without filters[1]:
> ----------------------------
>
> On x86-64
> Pure C | XviD SIMD yasm | XviD Edouard SIMD | lavc + SIMD
> Pass 1: N/A | 40fps | 45fps | 45fps
> Pass 2: N/A | 13fps | 14fps | 12fps
>
>
> On IA-32
> Pure C | XviD SIMD yasm | XviD Edouard SIMD | lavc + SIMD
> Pass 1: 10fps | N/A | 44fps | 42fps
> Pass 2: 3fps | N/A | 13fps | 11fps
>
>
> Comments:
> ---------
> - Lavc test is just here to compare how much a similar project gained
> from porting IA-32 SIMD ASM to x86-64.
>
> Conclusion:
> -----------
> - Edouard's AMD-64 port is faster than Andre Werthmann (based on
> XviD-1.0.2) ;-)
> - On AMD-64, there really is a speed-up, but it's limited.
>
>
> That's all for today, I'll try to test the qpel fix soon.
Thanks for the comparisons.
I'll just add that for the test:
> On IA-32
> Pure C | XviD SIMD yasm | XviD Edouard SIMD | lavc + SIMD
> Pass 1: 10fps | N/A | 44fps | 42fps
> Pass 2: 3fps | N/A | 13fps | 11fps
XviD SIMD yasm would give exactly the same speed, the only difference
between nasm and yasm output is that some short jumps are turned into
long jumps because nasm uses one more pass over the opcodes and can
post-determine that a long jump can be written as short jumps. But this
small difference is absolutly not significant.
You can test that simply letting the configure script doing its job, and
then hand editing the resulting platform.inc file, changing AS+nasm to
AS=yasm
Btw i'm testing the qpel fix right now, and started uploading the
resulting file back to my box, the PSNR results are much more conform to
a normal and expected encode.
===============================================================================
Two pass test name: underworld-trailer
Using cached first pass stats (hash - cddd58a4ebb392e39f2dfc9565f8dfca)
Results:
xvid: Min PSNR y : 31.60 dB, u : 38.47 dB, v : 44.53 dB, in frame 2581
xvid: Average PSNR y : 39.17 dB, u : 43.10 dB, v : 45.51 dB, for 3534 frames
xvid: Max PSNR y : 99.99 dB, u : 99.99 dB, v : 99.99 dB, in frame 1336
Filesize: 15318048 bytes
===============================================================================
With the qpel bug, avg psnr was around 38.89dB iirc.
--
Edouard Gomez
More information about the XviD-devel
mailing list