[Arm-netbook] libre-riscv, first update

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Wed, Dec 5, 2018 at 3:27 AM David Niklas <doark at mail.com> wrote:
>
> On Thu, 29 Nov 2018 10:34:12 +0000
> Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> > https://www.crowdsupply.com/libre-risc-v/m-class/updates/why-make-a-quad-core-64-bit-soc-surely-there-are-enough-already
> >
> > in case anyone's interested, do subscribe to updates.  i'll post links
> > here anyway.
> >
>
> luke, the kazan project says that it is a driver, whereas you say that it
> is a GPU "Onboard the Libre RISC-V M-Class is the Kazan GPU,..." at:
> https://www.crowdsupply.com/libre-risc-v/m-class
>
> I accessed the link on the kazan git page to see the risc-v GPU at:
> https://libre-riscv.org/3d_gpu/
> I noticed that you began a paragraph without mentioning what the heck
> the RVV thing is that you're talking about:
> "one of the things that's lacking from RVV..."
> Then you go off into "wonderland" explaining to us that gcc needs to have
> something (???) done to it to support RVV. Then you say that such a job
> would never have to be done again after Simple-V is through the
> "Extension Proposal Process" for "one single parallel / vector / SIMD
> instruction" without telling us why that would be the case and why no one
> has done such a thing before to make supporting GPUs, or are we still
> talking about RVV?, through gcc easier.

 yep, sorry, many of the pages there are memory-aides / notes, so as
not to lose track of what is an extremely complex project.

 RVV is the vectorisation extension for RISC-V:
 https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc

 the updates (2nd in editorial, 3rd in draft) are intended to be much
more the public conversation: unlike the eoma68 project there's just
not been time yet to get a discussion list up and running.

> I also see no mention of llvm in there,

 yes, i hadn't got round to updating that page.  there's actually
another one somewhere
https://libre-riscv.org/shakti/m_class/libre_3d_gpu/

> would we need to add support in
> both, only gcc, or what?

 ideally both.  we're currently evaluating ways to make a multi-issue
microarchitecture including branch-prediction, where if you don't use
SV, at least performance will be half-way decent, even at 800mhz.

 the key areas of focus are the inner loops for GPU and VPU.  these
initially will be written in inline assembler.  *once* both gcc and
llvm have support for whatever is found to be the best design, then
performance of standard code will catch up.

 http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2018-December/000198.html

 l.