[Arm-netbook] libre 64-bit risc-v SoC

[doark at 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 at lkcl.net> wrote:
>
> On Fri, Apr 28, 2017 at 12:47 PM, mike.valk at gmail.com
> <mike.valk at 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.

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

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

Sincerely,
David