[Arm-netbook] Allwinner outsells Intel

[joem]

On Fri, 2013-05-10 at 12:39 +0200, Vladimir Pantelic wrote:
> On 05/10/2013 12:21 PM, joem wrote:
> > On Fri, 2013-05-10 at 11:45 +0200, Vladimir Pantelic wrote:
> >> On 05/10/2013 09:40 AM, joem wrote:
> >>> The first attempt was the dual CPU ARM board
> >>> http://www.gplsquared.com/SoM1/SoM1.html
> >>>
> >>> Then I realize the bit rates for LCD is best
> >>> served by CPU with built in LCD controller, and even better with Linux
> >>> running to manage and use cheap A10 as the CPU and the even
> >>> higher pin counts matter. Could instead use USB/USB links as well,
> >>> but the overheads might cripple data transfer rates.
> >>> Current idea (which may change) is 32 bits for image in, 32 bits
> >>> for image out and a few control lines for hand shaking.
> >>
> >> so you want to use bitbanged GPIOs to pipe data from one CPU to the
> >> other? do you plan to poll the control lines thus hogging the CPU or to
> >> get an interrupt for each 32bit word?
> >
> > pass (because the boards have not been built yes - this conversation is
> > way too forward looking in a market that is constantly changing) - you
> > got around 16ms per frame, or about 16 million CPU instructions you can
> > execute before you must do something about that frame.
> >
> > Dropping a frame or part of a frame has no terrible consequences.
> >
> >>> So an n stage image pipeline can be built fairly easily.
> >>
> >> sure, the throughput will still by abysmal...
> >
> > Numbers?
> >
> > In what way?
> 
> You assume you can transfers one 32bit word over GPIO for every CPU 
> instruction, but as you wrote you need some kind of control logic around 
> that, so at best you will need 10-20 instruction per 32 bit word. So now 
> you are using 20-40% of your CPU for this data transfer and as you want 
> to chain CPUs, you need that done twice.

Well...  only the changes to a frame are required
to go through, so only if
everything changes in every frame do you hit peak transfer rates.
Even at full blast with your numbers, some 500 million CPU cycles are
still available for rendering.
If there is no data, flip a signal bit to indicate no data, and then
the 32 bit number on the video bus can be used to indicate how many
pixels to skip. The final stage remembers the current picture,
and only updates the changes sent down the video bus, and then makes
that new image the current picture.

There are many other tricks like this both in hardware and software
to optimize the rendering pipeline.


> Also, on existing SoCs most GPIO HW blocks are not even able to reach 
> that high data rates at all.
>
> Look at modern SoC and realize that all high speed data transfer units 
> are using dedicated HW blocks and not the CPU and bit banging ...

Block devices such as USB, ethernet and sata, sd card interfaces are not
doing anything useful, so those could be recruited for data transfer
from additional CPUs.

May be 6 months at least before getting to this project though.