[Arm-netbook] [review] SoC proposal

[Vladimir Pantelic]

lkcl luke wrote:
> On Wed, Feb 8, 2012 at 10:09 PM, Alec Ari<neotheuser at ymail.com>  wrote:
>
>>  You're asking for a ridiculously, and unrealistically optimized open source software engine,
>
>   no, i'm asking for opinions on how it can be achieved, not for
> opinions on how it will fail.  lots of people know how to fail: i'm
> looking for people who know how it can be *done*.
>
>
>>  and to have 1080p playback.... Current x86 CPUs, take the AMD Phenom II for example isn't even that great for Mesa's softpipe (100% software driver for Gallium) and you're talking about a low power ARM processor,
>
>   ah no, i'm not.  i didn't say ARM, did i?  i specifically avoided and
> made no mention of the RISC CPU core selected.  i mentioned ARC, and
> the reason i mentioned ARC is because the lead developer at Synopsys
> for the ARC RISC core also worked on the Video Decode Engine as well.
>
>   i _didn't_ mention that the CPU RISC core i'm looking at has VLIW
> support that roughly trebles its perceived clock-rate (instruction
> cycle execution rate).
>
>   anyway.
>
>   the ARC Video decode engine, we had a meeting with Synopsis and went
> over it.  there are over 1,000 video instruction extensions, and the
> Video DSP core in which those (SIMD) instructions are implemented has
> its own separate 128-bit-wide memory bus that the main CPU does *not*
> have access to.  it's a bit odd.
>
>   we evaluated the possibility of coping with 1080p30 video decode, and
> worked out that after one of the cores has been forced to deal with
> CABAC decode all on its own, the cores could then carry out the
> remaining parts of 1080p30 decode in parallel, at about 1ghz, quantity
> 4.

I would not recommend fully loading the cpu while decoding video, HD
video is becoming a commodity and people might soon use it as an "animated"
wallpaper while doing other CPU intensive stuff