Ricardo B (ricardo.b.delete@this.xxxxx.xx) on May 14, 2013 5:06 am wrote:
> RichardC (tich.delete@this.pobox.com) on May 14, 2013 3:54 am wrote:
> > Maynard Handley (name99.delete@this.name99.org) on May 13, 2013 6:52 pm wrote:
> >
> > > SMT) help with this to a small extent. They do help when I want certain tasks to run faster (the
> > > usual video encode, the slightly less usual large Mathematica jobs, the occasional situation where
> >
> > The specialized video transcode hardware handles that faster than threaded software.
>
> Yes it can.
> But lossy encoders are always a work in progress and the constantly evolving software encoders provide
> a better quality/file size ratio, less artifacts than fixed function hardware encoders.
>
> Using GPU for enconders, of course, gives almost the best of both worlds.

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.

> 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.