Re: [libdv-dev] Re: libdv for AMD64

[Dean K. <kol...@qw...>]

Before I fixed it up for x86-64, it was always being built entirely from C, 
no assembly language, and so slow it wasn't usable when built on x86-64.

Keep in mind there's a difference between building on x86-64 and running 
x86 code on an AMD64 machine. Apparently most people are running x86 
software on AMD64 machines. dvgrab seg faults on Fedora x86-64. mjpegtools 
seems to have x86 but not x86-64 assembly.

--disable-asm forces the new version to be built as all C, even if it could 
be build with assembly code, for comparison. It was intended to be usable, 
not faster than anything else.

I just made a line-for line fixup of the x86 assembly to get it to assemble 
on x86-64. Someone who really knows AMD64 should be able to speed it up 
quite a bit. There's also a lot of matrix arithmetic shortcuts to 
understand, but not documented.


At 07:00 PM 10/27/2004, Roman Shaposhnick wrote:
>On Wed, Oct 27, 2004 at 09:47:58PM -0400, Dan Dennedy wrote:
> > On Wed, 2004-10-27 at 00:13 -0700, Roman Shaposhnick wrote:
> > > On Wed, Oct 13, 2004 at 07:03:35AM -0400, Dan Dennedy wrote:
> > > > Thank you. I downloaded it, and will work on making sure it merges
> > > > nicely into my CVS working copy and test. Then, hopefully we get some
> > > > others to test.
> > >
> > >   Well CVS obviously works on Opteron/SuSE 8. So that's covered. Now
> > >   for the bad news. For some reason it takes almost twice the time to
> > >   decode pond.dv (8.7 user) compared to the ffmpeg with x86_64
> > >   enabled DV decoder (4.7 user).
> >
> > Dean did say it was not optimised for 64bit, just a minimal port. I
> > expect ffmpeg to be better - both 32 and 64bit. The real comparison to
> > be made is against --disable-asm.
>
>   I kinda lost you here. Why --disable-asm is important ? It's known
>   to be way slower anyway.
>
> > A user sent an e-mail after my
> > announcement on kino forum, and said his system worked fine with the
> > current libdv release. I told him that asm/mmx was disabled due to arch
> > detection at configure. I asked him to try CVS, he did, and reported a
> > huge performance gain, of course.
>
>   Hm. I went and checked and I saw the following .o's under .lib/:
>
>     dct_block_mmx_x86_64.o
>     encode_x86_64.o
>     idct_block_mmx_x86_64.o
>     quant_x86_64.o
>     rgbtoyuv_x86_64.o
>     transpose_x86_64.o
>
>   so it would seem that x86_64 support gets used.
>
> > Also, Kino's bugtracker http://jira.schirmacher.de/ contains a segfault
> > with backtrace bug report of an amd64 user using kino compiled against
> > libavcodec. It should be easy to spot in the list. However, it contains
> > no libavcodec version indication. As a matter of fact, that sort of
> > thing is rather hard for users to track and report as many ffmpeg users
> > are not using an official ffmpeg release.
>
>   Interesting. Of course ffmpeg's stable release is long overdue, but
>   CVS should be quite stable as far as DV is concerned. Are you sure
>   that it failed in DV decoding, not when user tried to export stuff
>   into mpeg4 or something.
>
>   Anyway, tomorrow I'll give it a try on my Opteron box.
>
>Thanks,
>Roman.
>
>P.S. Of course I'm biased, but it seems that Sun manufactures a real killer
>Opteron boxes...