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

On Wed, Dec 5, 2018 at 3:27 AM David Niklas doark@mail.com wrote:

On Thu, 29 Nov 2018 10:34:12 +0000 Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:

...

https://www.crowdsupply.com/libre-risc-v/m-class/updates/why-make-a-quad-cor...

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....

l.