[Arm-netbook] [review] SoC proposal
vladoman at gmail.com
Thu Feb 9 07:41:18 GMT 2012
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).
> 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
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
More information about the arm-netbook