<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-05-07 22:26 GMT+02:00  <span dir="ltr"><<a href="mailto:doark@mail.com" target="_blank">doark@mail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I apologize for DOS'ing the list, I can only get online about once a week.<br>
<br>
On Fri, 28 Apr 2017 13:58:57 +0100<br>
Luke Kenneth Casson Leighton <<a href="mailto:lkcl@lkcl.net">lkcl@lkcl.net</a>> wrote:<br>
<span class="gmail-">><br>
> On Fri, Apr 28, 2017 at 12:47 PM, <a href="mailto:mike.valk@gmail.com">mike.valk@gmail.com</a><br>
> <<a href="mailto:mike.valk@gmail.com">mike.valk@gmail.com</a>> wrote:<br>
><br>
> > If you're trying to trans-code something that you don't have a<br>
> > co-processor/module for you're forced to CPU/GPU trans-coding.<br>
><br>
</span><span class="gmail-">>  you may be misunderstanding: the usual way to interact with a GPU is<br>
> to use a memory buffer, drop some data in it, tell the GPU (again via<br>
> a memory location) "here, get on with it" - basically a<br>
> hardware-version of an API - and it goes an executes its *OWN*<br>
> instructions, completely independently and absolutely nothing to do<br>
> with the CPU.<br>
><br>
>  there's no "transcoding" involved because they share the same memory<br>
> bus.<br>
><br>
</span><span class="gmail-">> > Would a FPGA<br>
> > still be more power huns gry then?<br>
><br>
</span>>  yes.<br>
<span class="gmail-">><br>
> > I think/hope FPGA's are more efficient for specific tasks then<br>
> > CPU/GPU's<br>
><br>
</span><span class="gmail-">>  you wouldn't give a general-purpose task to an FPGA, and you wouldn't<br>
> give a specialist task for which they're not suited to a CPU, GPU _or_<br>
> an FPGA: you'd give it to a custom piece of silicon.<br>
<br>
</span>I always thought that FPGA's were good for prototyping or small fast<br>
tasks... But that's just how I learned about them.<br></blockquote><div><br></div><div>Don't think of what you were thought. Think of what you can do which has not been thought.</div><div><br></div><div>The world outside the box is bigger than the on inside the box ;-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
>  in the case where you have something that falls outside of the custom<br>
> silicon (a newer CODEC for example) then yes, an FPGA would *possibly*<br>
> help... if and only if you have enough bandwidth.<br>
><br>
</span><span class="gmail-">>  video is RIDICULOUSLY bandwidth-hungry.  1920x1080 @ 60fps 32bpp<br>
> is... an insane data-rate.  it's 470 MEGABYTES per second.  that's<br>
> what the framebuffer has to handle, so you not only have to have the<br>
> HDMI (or other video) PHY capable of handling that but the CODEC<br>
> hardware has to be able to *write* - simultaneously - on the exact<br>
> same memory bus.<br>
><br>
</span><snip><br>
Your number seemed off to me so I did the math:<br>
1920*1080*60*4 ==<br>
497,664,000<br>
You're off by almost 30 MiB.<br></blockquote><div><br></div><div>497,664,000 ~= 498 MB (Units of 1000)<br></div><div>497,664,000 ~= 475 MiB (Units of 1024)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Most video cameras (that I've been able to locate), do 24bpp, 640x480 at<br>
30fps, so that would make the bandwidth requirements.<br>
27,648,000<br></blockquote><div><br></div><div>I was specifically hinting at decoding. That's the most used function. But encoding should these days also be capable of FullHD</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Which should be more reasonable for an FPGA (not that I have all the<br>
specs sitting in front of me, mind you).<br>
I am assuming that "encoding video" means encoding from a video camera or<br>
a small youtube video as opposed to encoding to send to a device over,<br>
say, an HDMI cable.<br></blockquote><div><br></div><div>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.  </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
><br>
> > We can always have evolution create a efficient decoder ;-)<br>
> > <a href="https://www.damninteresting.com/on-the-origin-of-circuits/" rel="noreferrer" target="_blank">https://www.damninteresting.<wbr>com/on-the-origin-of-circuits/</a><br>
><br>
</span><snip><br>
<br>
Sincerely,<br>
David<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
______________________________<wbr>_________________<br>
arm-netbook mailing list <a href="mailto:arm-netbook@lists.phcomp.co.uk">arm-netbook@lists.phcomp.co.uk</a><br>
<a href="http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook" rel="noreferrer" target="_blank">http://lists.phcomp.co.uk/<wbr>mailman/listinfo/arm-netbook</a><br>
Send large attachments to <a href="mailto:arm-netbook@files.phcomp.co.uk">arm-netbook@files.phcomp.co.uk</a></div></div></blockquote></div><br></div></div>