Comment by tyami94 | Hacker News Reader

Comment by tyami94 | Hacker News Reader

Parent Full thread

I can't say I agree with you here, if anything FPGAs and general purpose microprocessors go hand in hand. It would be an absolute game changer to be able to literally download hardware acceleration for a new video codec or encryption algorithm. Currently this is all handled by fixed function silicon which rapidly becomes obsolete. AV1 support is only just now appearing in mainstream chips after almost 8 years, and soon AV2 will be out and the cycle will repeat.

This is such a severe problem that even now, (20+ year old) H.264 is the only codec that you can safely assume every end-user will be able to play, and H.264 consumes 2x (if not more) bandwidth compared to modern codecs at the same perceived image quality. There are still large subsets of users that cannot play any codecs newer than this without falling back to (heavy and power intensive) software decoding. Being able to simply load a new video codec into hardware would be revolutionary, and that's only one possible use case.

> It would be an absolute game changer to be able to literally download hardware acceleration for a new video codec or encryption algorithm

That relies on "FPGAs everywhere", which is much further out than "GPUs everywhere".

I'm not sure where the state of the art is on this, but given the way that codecs work - bitstream splitting into tiles, each of which is numerically heavy but can be handled separately - how is development of hybrid codecs, where the GPU does the heavy lifting using its general purpose cores rather than fixed function decoder pipeline?

But why would it be amazing? The alternative right now is that you do it in software and just dedicate a couple of cores to the task (or even just put in a separate $2 chip to run the decoder).

Like, I get the aesthetic appeal, and I accept that there is a small subset of uses where an FPGA really makes a difference. But in the general case, it's a bit like getting upset at people for using an MCU when a 555 timer would do. Sure, except doing it the "right" way is actually slower, more expensive, and less flexible, so why bother?

Battery powered or thermally constrained devices.

You definitely don't want an FPGA if those are your concerns.

...which are playing back video, so they're likely blowing most of their power budget on the display and on radio. I guess my threshold of "amazing" is different. Again, I'm not denying some incremental utility in specialized uses, but most of the time, it just doesn't seem to be worth the pain - especially since nothing about the implementation will be portable or maintainable in the long haul.

In the same vein, no one is writing a smartwatch software stack in 100% bare-metal assembly, although in the hands of a capable developer, I'm sure it could prolong battery life.

And you think that a downloaded codec on an FPGA would perform anywhere close to custom silicon? Because it won't; configurability comes at a steep cost.

FPGAs are more like CGRAs these days. With the right DSP units, it could absolutely be competitive with custom silicon.

Reply on news.ycombinator.com