[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