[XviD-devel] Request: optimized version of image_setedges

[peter ross]

>From: "Michael Militzer" <michael@xvid.org>
>Reply-To: xvid-devel@xvid.org
>To: <xvid-devel@xvid.org>
>Subject: Re: [XviD-devel] Request: optimized version of image_setedges
>Date: Tue, 9 Jul 2002 00:30:38 +0200
>
>----- Original Message -----
>From: "Christoph Lampert" <chl@math.uni-bonn.de>
>To: <xvid-devel@xvid.org>
>Sent: Sunday, July 07, 2002 1:53 PM
>Subject: Re: [XviD-devel] Request: optimized version of image_setedges
>
>
> > Fine. I was just looking around to see what could possibly be
> > multithreaded. I though of image_interpolate, because it used to be 
>rather
> > slow, but now there doesn't seem to be a real #1 candidate at the 
>moment.
> > Maybe I manage to put whole FrameCodeP into several threads...
>
>Hm, it seems that it's no bad idea to try to write a SMP aequivalent for
>FrameCodeP and FrameCodeI. The new functions (FrameCodeP_SMP etc.) could be
>simply additionally included to encoder.c and nothing will be different for
>single-cpu mode. Especially the code wouldn't become too hard to understand
>because only 2 "normal" functions would be replaced by SMP aware ones.
>
>The motion_estimation call has of course to be moved back into the big 
>for()
>loop again for the SMP variant then the for() loop could be multithreaded. 
>I
>suppose this would give a good speed gain and also should scale pretty
>well...
>
>How's the status of your SMP aware FrameCodeP function?
>

the code "inside" each of the FrameCode[I,P,B] loops is going to be the same 
for non-smp and smp. why not place these in individual function. such as 
FrameCode[I,P,B]_MB?

i'am in favour of adding a 'num_thread' field to XVID_ENC_PARAM when #def 
SMP. if num_thread <= 0 then use non-smp, else smp.

-- pete


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx