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

[mike.valk at gmail.com]

2017-05-07 22:26 GMT+02:00 <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.
>

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 at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20170508/6645d078/attachment-0001.html>