Discussion:
[Arm-netbook] libre-riscv, first update
Luke Kenneth Casson Leighton
2018-11-29 10:34:12 UTC
Permalink
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.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm
David Niklas
2018-12-05 03:25:53 UTC
Permalink
On Thu, 29 Nov 2018 10:34:12 +0000
Post by Luke Kenneth Casson Leighton
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.

I also see no mention of llvm in there, would we need to add support in
both, only gcc, or what?

Thanks!

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcom
Luke Kenneth Casson Leighton
2018-12-05 03:51:41 UTC
Permalink
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by David Niklas
On Thu, 29 Nov 2018 10:34:12 +0000
Post by Luke Kenneth Casson Leighton
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
https://www.crowdsupply.com/libre-risc-v/m-class
https://libre-riscv.org/3d_gpu/
I noticed that you began a paragraph without mentioning what the heck
"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.
Post by David Niklas
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/
Post by David Niklas
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.p

Loading...