[Open-graphics] decoding video in real-time
James Richard Tyrer
tyrerj at acm.org
Thu Mar 22 21:47:15 EDT 2007
Dieter wrote:
>> Video decoding is hard to parallelize on general purpose
>> CPUs. Thus even if it has two ALUs, you will not be able
>> to use both to their full potential. Specialized video
>> decoding hardware is much better in that case.
>>
>> Also keep in mind, that having two processors does not
>> mean you have doubled your processing power. How much
>> you get depends a lot on:
>> 1) How well you can parellize the work tasks.
>
> One way to parallelize a process is splitting it up into pieces
> that can run independently in serial, then running it on a SMP
> machine. AMD's x2 chips are coming down in price, and x4 chips
> should be available soon. So this is starting to become practical.
>
> The trick will be figuring out how and where to divide a monolithic
> program into pieces. Ideally you'd want each piece to take about
> tha same amount of CPU, since SMP machines usually have identical
> CPUs. And pieces that the GPU can do would ideally go at the end
> to avoid having to ship data back and forth.
I don't know if this is possible with MPEG decoding. I think that it
lends itself more to hardware acceleration.
IIRC, this was one of the goals of JPEG 2k -- to design it so that it
could be done by multiple processors running multiple threads.
If the MPEG decoding requires a lot of X pixel IDCTs then special
purpose hardware that can rapidly do an X pixel IDCT would be a great
help. This would work best if it could be pipelined since the pipe is
going to be rather long. Also, IIUC, the code contains a lot of MACs
and requires multiple accumulator registers and s system that is SIMD.
In both cases, these are hardware accelerators that accelerate a single
thread. OTOH, there is the fractional pixel block move which could
operate in parallel, but still in a single thread.
--
JRT
More information about the Open-graphics
mailing list