Hi,

On Fri, 20 Feb 2015 03:03:08 -0800 (PST) [email protected] wrote:
> On Tuesday, February 17, 2015 at 6:56:13 PM UTC+1, Manuel Braga wrote:
> > On Tue, 17 Feb 2015 12:00:27 +0200 Simos Xenitellis
> > > 
> > > At http://www.phoronix.com/scan.php?page=news_item&px=MTg4Mjg it
> > > mentions that Intel is doing Linux work on the PowerVR VXD392 VPU
> > > (as is used on Baytrail).
> > > Is the VPU similar to what exists on the A80?
> > 
> > What is a VPU?, wikipedia says that a VPU is another term for GPU.
> > And at the end this is huge confusion, that make people believe
> > that for have hardware accelerated video playback is a requirement
> > to have and use the GPU.
> 
> CPU : Central Processing Unit
> GPU : Graphics Processing Unit
> VPU : Video Processing unit
> 
> GPU, VPU are specialized processing unit/cores for specific workloads
> to unload the CPU or gain performance which is out of reach for a
> general purpose PU 
> 
> GPGPU: General purpose GPU. -> OpeCL etc. 
> 
> Not that confusing IMHO, A little archaic perhaps. 

Tell that to wikipedia, for them the V is not for "video", but "visual".
http://en.wikipedia.org/w/index.php?title=Video_processing_unit&redirect=no

> 
> > 
> > This is wrong, it come from the fact that in the PC(x86) world are
> > used graphic cards that are actually are (gpu + display engine +
> > video codec engine), so this is 3 kind of difference hardware types
> > put together in this some called graphic card.
> > As this graphic card is one identity, it is usually all handled by
> > the same software driver.
> 
> In x86 land we started with CGA, EGA and VGA cards. Which were a
> little more than "Diplay Controllers". And were called "video cards"
> which was used pre x68. Because the C64 etc used a "composite video
> signal" to interface with tv's/display's
> 
> Than came the "graphics accelerators", which would offload graphics
> processing from the CPU and send results back to CPU or directly to
> the display controller. 
> 
> http://commons.wikimedia.org/wiki/File:VideoLogic_Apocalypse_3Dx.jpg#mediaviewer/File:VideoLogic_Apocalypse_3Dx.jpg
> An ancient PowerVR GPU for x86 without the display controller.
> 
> 
> Because the chain CPU->GPU/Display Controller->Display. The display
> controller became embedded to the GPU cards.
> 
> Apart from that the came MPEG cards wich would decode MPEG video and
> 'stream' the result back to the system.
> 
> Because video decoding, VPU, should at the same place as the GPU the
> chain is broken. CPU -> VPU -> CPU -> GPU -> Display
> 
> Thus most GPU cards now have a video decoder onboard as well.
> CPU -> VPU/GPU/Display Controller -> Display
> 
> > 
> > In ARM case this is not the case,
> > http://www.cnx-software.com/2013/12/10/most-embedded-gpus-do-not-support-hardware-video-decoding-acceleration-the-vpu-does/
> 
> The driver issue is more a "Mix and Match" issue. In x86 the
> GPU/VPU/Display Controller are usually on one device. The set is
> alway the same and using a single driver makes sense. 
> 
> In ARM land the CPU,GPU,VPU,Display Controller are mixed and matched
> on a single device. Thus a single driver does not make sense. Hence
> the need for seperate drives and some glue (DeviceTree). Also the
> parts are no longer aligned but are placed side by side on the same
> memory(bus).
> 
> Luc has mostly figured out the Mali GPU and is now working on the
> display controller.

Thanks for helping make things more clear.


> 
> For A312 and A80 they chose Imagination's PowerVR as the GPU, I don't
> know if they chose the use Imagination parts for the Display
> Controller and VPU

For the "VPU", there isn't a reason why it is not the same as from all
other socs. Moreover in the datasheets the features match in equal mode.
Also same simple kernel driver. 

But as i don't own A31*/A80 devices, i can't take the 30 minutes that
would take to make this clear without any doubt.


> 
> > 
> > Please lets use a more correct term, that creates no ambiguity of
> > what we are speaking about.
> > 
> > Video Codec Engine, is the correct name for this type hardware in
> > the sunxi(allwinner) case. This is the hardware to use for decoding
> > and encoding of video codecs.
> 
> codec comes from coding and decoding. The VPU does more:
> ColorCode conversion
> Scaling
> etc.
> 
> So calling it a mere codec is not more accurate.
> 
> "Media Processing Unit" I think is better. It whould also cover the
> audio codec and remove the confusion with "video cards"

http://linux-sunxi.org/Category:Video_Engine

Let's call it "Media Accelerate Video Engine"


> 
> But the Market/Marketing is stuck on the "video" term. 

Allwinner is simply calling "video engine".


> 
> > 
> > And in sunxi, sometimes called also "cedar engine" and it is the
> > *same* Video Codec Engine in all allwinner socs.
> > A10/A10s/A13/A20/A23/A31/A31s/A33/A80/A80T/A83T/H3/H8
> > (with some minor and or new feature hardware versions)
> > 
> > How do i know?
> > From the kernel source code make available from allwinner.
> > 
> > To the best of what could be found, this Video Codec Engine is a
> > custom design made by www.chipsbank.com for allwinner. And this
> > makes believe that is allwinner propriety and only used in
> > allwinner socs.
> 
> That's intersting. I thought, altough it seemed odd me, the VPU was
> an in house development of Allwinner.
> 
> So the CedarX code may also be property of chipsbank.

This hint came from the email address of one the the authors of the
cedar engine kernel driver.


> 
> Does chipsbank provide "open" documentation?

Do you think so?




But there isn't anything more hidden.
http://linux-sunxi.org/VE_Register_guide
http://linux-sunxi.org/CedarX/Reverse_Engineering


-- 
thanks for reading

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to