--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, Dec 5, 2018 at 3:27 AM David Niklas <[email protected]> wrote: > > On Thu, 29 Nov 2018 10:34:12 +0000 > Luke Kenneth Casson Leighton <[email protected]> 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. _______________________________________________ arm-netbook mailing list [email protected] http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to [email protected]
