Re: multimedia/xvid

2008-10-12 Thread Carlos A. M. dos Santos
On Sat, Oct 11, 2008 at 1:59 PM, Michel Talon [EMAIL PROTECTED] wrote:
 On Sun, Oct 12, 2008 at 12:42:08AM +1100, Sean Winn wrote:

 Another option is to just fix the configure script so it doesn't break on
 nasm  1 (it's failing on the patch level check)

 The attached file dropped in ports/multimedia/xvid/files/ seems to do the
 trick, though I don't use xvid so I can't exactly test that the new version
 assembles things properly.

 Something done to configure.in should be sent upstream really.

 Yes, fixing the configure script should be done upstream, but it
 seems that the xvid project is somewhat asleep, so better use
 yasm in the Makefile on which there is control. As you note below,
 the problem comes because the configure script tries to use the -r
 option which yasm has but not nasm, so the xvid people had really
 yasm in view when doing their work.


 --- configure.orig2008-10-11 13:40:34.0 +1100
 +++ configure 2008-10-11 13:43:14.0 +1100
 @@ -4016,7 +4016,12 @@
 if test $ac_nasm = yes ; then
  echo $as_me:$LINENO: checking 
 for nasm patch version 5
  echo $ECHO_N checking for nasm patch version... $ECHO_C 6
 -   nasm_patch=`$nasm_prog -r | cut -d '.' -f 3 | cut -d ' ' -f 1`
 +nasm_version=`$nasm_prog -v | cut -d '.' -f 1 | cut -d ' ' -f3`
 +if test -n $nasm_version -a $nasm_version -gt 1; then
 + nasm_patch=$minimum_nasm_patch_version
 +else
 + nasm_patch=`$nasm_prog -r | cut -d '.' -f 3 | cut -d ' ' -f 1`
 +fi
 if test -z $nasm_patch ; then
nasm_patch=-1
 fi

 By the way, the performance improvement obtained by using SSE
 instructions in the assembly files is astounding.  I could not beleive
 what i was seeing, basically an x 4 improvement, that is the code
 perfectly parallelizes the computations on the 128 bits registers.
 This is a good illustration of the fact that compilers are not always
 as smart as people say, and assembly code can crush C code.

I just submitted a PR with the fix:

 http://www.freebsd.org/cgi/query-pr.cgi?pr=128042

-- 
cd /usr/ports/sysutils/life
make clean
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: multimedia/xvid

2008-10-11 Thread Michel Talon
On Fri, Oct 10, 2008 at 10:11:35PM -0300, Carlos A. M. dos Santos wrote:
 
 Standard questions:
 
 1. O which architectures did you test this?

On a P4 HTT. I can test that on an Athlon T Bird and a Core 2 Duo 
in 386 mode, but i don't have access to an amd64 machine running
FreeBSD, and of course other architectures. The assembly files in
question contain MMX,SSE and SSE2 instructions so apply only to
such processors.

 2. Did you send a PR?

No

 3. The port currently has no maintainer. Would you like to take it? :-)

I have no problem taking it, on the other hand the required modification
is minimal. I have checked on the xvid site that there is no more recent
version.

-- 

Michel TALON

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: multimedia/xvid

2008-10-11 Thread Carlos A. M. dos Santos
On Sat, Oct 11, 2008 at 4:37 AM, Michel Talon [EMAIL PROTECTED] wrote:
 On Fri, Oct 10, 2008 at 10:11:35PM -0300, Carlos A. M. dos Santos wrote:

 Standard questions:

 1. O which architectures did you test this?

 On a P4 HTT. I can test that on an Athlon T Bird and a Core 2 Duo
 in 386 mode, but i don't have access to an amd64 machine running
 FreeBSD, and of course other architectures. The assembly files in
 question contain MMX,SSE and SSE2 instructions so apply only to
 such processors.

 2. Did you send a PR?

 No

 3. The port currently has no maintainer. Would you like to take it? :-)

 I have no problem taking it, on the other hand the required modification
 is minimal. I have checked on the xvid site that there is no more recent
 version.

I gave it a try and found that configure needs some help on AMD64
because it expects the architecture name to be x86_64, not amd64.
Could you please check if the attached Makefile works on i386? I can
not test it because I only have 8.0-CURRENT on AMD64 at the moment.

-- 
cd /usr/ports/sysutils/life
make clean


Makefile
Description: Binary data
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: multimedia/xvid

2008-10-11 Thread Michel Talon
On Sun, Oct 12, 2008 at 12:42:08AM +1100, Sean Winn wrote:
 
 Another option is to just fix the configure script so it doesn't break on
 nasm  1 (it's failing on the patch level check)
 
 The attached file dropped in ports/multimedia/xvid/files/ seems to do the
 trick, though I don't use xvid so I can't exactly test that the new version
 assembles things properly.
 
 Something done to configure.in should be sent upstream really.

Yes, fixing the configure script should be done upstream, but it
seems that the xvid project is somewhat asleep, so better use
yasm in the Makefile on which there is control. As you note below,
the problem comes because the configure script tries to use the -r
option which yasm has but not nasm, so the xvid people had really
yasm in view when doing their work.


 --- configure.orig2008-10-11 13:40:34.0 +1100
 +++ configure 2008-10-11 13:43:14.0 +1100
 @@ -4016,7 +4016,12 @@
 if test $ac_nasm = yes ; then
  echo $as_me:$LINENO: checking 
 for nasm patch version 5
  echo $ECHO_N checking for nasm patch version... $ECHO_C 6
 -   nasm_patch=`$nasm_prog -r | cut -d '.' -f 3 | cut -d ' ' -f 1`
 +nasm_version=`$nasm_prog -v | cut -d '.' -f 1 | cut -d ' ' -f3`
 +if test -n $nasm_version -a $nasm_version -gt 1; then
 + nasm_patch=$minimum_nasm_patch_version
 +else
 + nasm_patch=`$nasm_prog -r | cut -d '.' -f 3 | cut -d ' ' -f 1`
 +fi
 if test -z $nasm_patch ; then
nasm_patch=-1
 fi

By the way, the performance improvement obtained by using SSE
instructions in the assembly files is astounding.  I could not beleive
what i was seeing, basically an x 4 improvement, that is the code
perfectly parallelizes the computations on the 128 bits registers.
This is a good illustration of the fact that compilers are not always 
as smart as people say, and assembly code can crush C code. 


-- 

Michel TALON

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: multimedia/xvid

2008-10-11 Thread Carlos A. M. dos Santos
On Sat, Oct 11, 2008 at 12:42 PM, Michel Talon [EMAIL PROTECTED] wrote:
 I gave it a try and found that configure needs some help on AMD64
 because it expects the architecture name to be x86_64, not amd64.
 Could you please check if the attached Makefile works on i386? I can
 not test it because I only have 8.0-CURRENT on AMD64 at the moment.

 Your Makefile allows xvid to compile without any problem on x86.
 I have also checked that xvid builds on a clean machine, without
 nasm or yasm installed with your Makefile, so it seems to be fine.

 Thanks for your attention.

Nice. Is there anybody in the list able to try the assembly options
for IA64 and PPC? I know I'm pushing a little bit, but it would be
nice if we could make the port work better on other platforms too.

-- 
cd /usr/ports/sysutils/life
make clean
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: multimedia/xvid

2008-10-10 Thread Carlos A. M. dos Santos
On Thu, Oct 9, 2008 at 9:28 AM, Michel Talon [EMAIL PROTECTED] wrote:
 Trying to encode with mencoder and the xvid codec(*), i discovered that it
 is awfully slow (around 3 frames/s on my P4 machine). So i played a
 little bit with the options in the Makefile without any success. Finally
 i understood that the cause was that the build system requires nasm, but
 doesn't use it! There are several assembly files in the xvid codec which
 are not used due to that. The solution i have found by looking at the
 configure script is to install the yasm port. Then the build system
 picks the yasm dependency and compiles the assembly files, which enables
 SSE instructions. The net result is that, without any other tweak, i now
 encode the same stuff at 11 frames/s.

 So to be short, multimedia/xvid should require a dependency on yasm.

 (*) in find that the end result is better (less artifacts at the same
 bitrate) with xvid than with lavc.

Standard questions:

1. O which architectures did you test this?
2. Did you send a PR?
3. The port currently has no maintainer. Would you like to take it? :-)

-- 
cd /usr/ports/sysutils/life
make clean
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: multimedia/xvid and USE_GCC

2007-05-25 Thread Michael Nottebrock
On Friday, 25. May 2007, Yuri Pankov wrote:
 Hi,

 Is there a reason why multimedia/xvid uses USE_GCC?= 3.4 and not
 USE_GCC?= 3.4+? Now that gcc-4.2.0 is in base on -CURRENT, it builds and
 apps using it seem to run just fine with 4.2.

Nope, just an oversight. Should be fixed now.

Cheers,
-- 
   ,_,   | Michael Nottebrock   | [EMAIL PROTECTED]
 (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
   \u/   | K Desktop Environment on FreeBSD | http://freebsd.kde.org


pgpkEMhRMdzvj.pgp
Description: PGP signature