[XviD-devel] GPU Fragment Processor Acceleration of XviD encoding

Bryan Mayland bmayland at leoninedev.com
Wed Oct 11 21:36:16 CEST 2006


Dan wrote:
> I am, unfortunately, totally new to the programmatic workings of XviD.  I
> will ramp up on this, but in the meantime, if anyone is able and willing to
> give me any points on where the most computationally intensive part of the 
> code is, it would help me tremendously.  I don't yet know how much time I can
> dedicate to this, but I think it would be a very interesting result if 
> significant speedups became available.
>   
    You can enable internal profiling in the code which will spit out a 
text file that details how much time is spent in each step of the 
encoding process.  That's in the ./configure script as --enable-iprofile 
iirc.

    I can get you started though.  The greatest amount of time by far is 
spent doing motion search, about 50%.  This is why there are patches by 
various authors (myself included) to multi-thread the motion search.  I 
don't know how well this translates to a GPU though, due to the large 
number of texture reads needed to perform just one search iteration for 
one macroblock. 

    Your best bet is to turn on the profiling and take it from what you 
see there.  I'm very interested in seeing what ideas you come up with 
for what to offload to the GPU.  I've done contracts doing commercial 
shader effects so I'm very familiar with the architecture, but never 
could nail down a good candidate for optimization.




More information about the XviD-devel mailing list