2017-05-07 22:26 GMT+02:00 <do...@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 <l...@lkcl.net> wrote: > > > > On Fri, Apr 28, 2017 at 12:47 PM, mike.v...@gmail.com > > <mike.v...@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-netb...@files.phcomp.co.uk >
_______________________________________________ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
