2017-05-07 22:26 GMT+02:00 <doark@mail.com>:

I apologize for DOS'ing the list, I can only get online about once a week.

On Fri, 28 Apr 2017 13:58:57 +0100
Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>
> On Fri, Apr 28, 2017 at 12:47 PM, mike.valk@gmail.com
> <mike.valk@gmail.com> wrote:
>
> > If you're trying to trans-code something that you don't have a
> > co-processor/module for you're forced to CPU/GPU trans-coding.
>
> you may be misunderstanding: the usual way to interact with a GPU is
> to use a memory buffer, drop some data in it, tell the GPU (again via
> a memory location) "here, get on with it" - basically a
> hardware-version of an API - and it goes an executes its *OWN*
> instructions, completely independently and absolutely nothing to do
> with the CPU.
>
> there's no "transcoding" involved because they share the same memory
> bus.
>
> > Would a FPGA
> > still be more power huns gry then?
>
> yes.
>
> > I think/hope FPGA's are more efficient for specific tasks then
> > CPU/GPU's
>
> you wouldn't give a general-purpose task to an FPGA, and you wouldn't
> give a specialist task for which they're not suited to a CPU, GPU _or_
> an FPGA: you'd give it to a custom piece of silicon.

I always thought that FPGA's were good for prototyping or small fast
tasks... But that's just how I learned about them.

Don't think of what you were thought. Think of what you can do which has not been thought.

The world outside the box is bigger than the on inside the box ;-)

> in the case where you have something that falls outside of the custom
> silicon (a newer CODEC for example) then yes, an FPGA would *possibly*
> help... if and only if you have enough bandwidth.
>
> video is RIDICULOUSLY bandwidth-hungry. 1920x1080 @ 60fps 32bpp
> is... an insane data-rate. it's 470 MEGABYTES per second. that's
> what the framebuffer has to handle, so you not only have to have the
> HDMI (or other video) PHY capable of handling that but the CODEC
> hardware has to be able to *write* - simultaneously - on the exact
> same memory bus.
>
<snip>
Your number seemed off to me so I did the math:
1920*1080*60*4 ==
497,664,000
You're off by almost 30 MiB.

497,664,000 ~= 498 MB (Units of 1000)

497,664,000 ~= 475 MiB (Units of 1024)

Most video cameras (that I've been able to locate), do 24bpp, 640x480 at
30fps, so that would make the bandwidth requirements.
27,648,000

I was specifically hinting at decoding. That's the most used function. But encoding should these days also be capable of FullHD

Which should be more reasonable for an FPGA (not that I have all the
specs sitting in front of me, mind you).
I am assuming that "encoding video" means encoding from a video camera or
a small youtube video as opposed to encoding to send to a device over,
say, an HDMI cable.

The problem is that the FPGA has to be very big or very fast. FPGA are, apparently, not very fast thus they need to be big. Bandwith x speed. The'res not enough space.

>
> > We can always have evolution create a efficient decoder ;-)
> > https://www.damninteresting.com/on-the-origin-of-circuits/
>
<snip>

Sincerely,
David

_______________________________________________
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook@files.phcomp.co.uk