Michael S (already5chosen.delete@this.yahoo.com) on May 14, 2013 5:45 am wrote:
> Except that, unlike CPU, sw developer can't rely on the presence of GPGPU on
> user's machine. Even less so on the presence of GPGPU of specific brand.

Software developers also can't also rely on the presence of a particular SIMD extension in a CPU. Hasn't stopped them from implementing multiple code paths to deal with it

OpenCL provides a good enough abstraction of different GPGPU brand/models.
Targeting a generic OpenCL may not extract all the possible performance, but it's enough to handly beat the CPU encoder.


> > But even then, there are some stages of the encoding which
> > is best implemented in the CPU and are SMT friendly.
> >
>
> Except for the final entropy encoding stage (Huffman, arithmetic or similar) which part
> of video encoders is bot SMT friendly and poorly suitable for implementing in [GP]GPU?
>
> And entropy encoding itself is so tiny part of the total encode job that it hardly justifies
> major HW feature. At best, it can justify addition of couple of instructions.

IIRC, motion compensation is also very branchy.