[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