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.
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
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
arm-netbook@lists.phcomp.co.uk
-
doark＠mail.com -
mike.valk＠gmail.com