[Arm-netbook] Libre RISC-V RV64GC SoC

[mike.valk at gmail.com]

2017-12-29 6:48 GMT+01:00 Luke Kenneth Casson Leighton <lkcl at lkcl.net>:
> On Thu, Dec 28, 2017 at 9:56 PM, Bill Kontos <vkontogpls at gmail.com> wrote:
>> If this goes
>> well it will go down in history as one of those famous conversations
>> in the early days of tech we read about.
>
>  yehyeh!

I think so too. And India is very keen on becoming the next
China/Taiwan/Etc. Which I think is a good thing.

>> This is something that I don't get with the shakti project. How are
>> they planning to tackle the 2d/3d/vpu problem?
>
>  also on opencores there's a series of hard macros with basic video
> primitives, including cabac decode and many more: dropping lots and
> lots of those in will go a long *long* way towards being able to
> tackle 2D, 3D and a VPU.
>
>  the key here though is: it is *really* necessary to find a full
> software team to get the userspace stuff done *at the same time* and
> on emulated FPGAs so that performance can be verified / estimated.
>
>
2D: Skip. AMD and Vivante already do so, NVIDIA will too IIRC. The 2D
accelerators were mostly for windowing systems now replaced by
composting systems, including MS Windows, and other means, Androids
SurfaceFlinger, etc. The missing functions are now done on 3D or CPU.

VPU: That would require also licenses from the format owners. That's
going to be difficult. And the new, open, video formats are not ready.
Daala, Thor, NETVC, AV1.

Something generic to offload parts of the decoding/encoding would be
the best bet I guess. Avoids licenses, single format isolation. IIRC
most codecs share techniques. I might be talking jibberisch, or it
might be to impractical.

3D. Wasn't there a PoC from some students in the open macro's? Perhaps
those guys can be hired to refine their work?