[libre-riscv-dev] openrisc1200

[Luke Kenneth Casson Leighton]

On Tue, Jan 21, 2020 at 4:53 PM Adam Van Ymeren <adam at vany.ca> wrote:

> On 2020-01-21 10:16 AM, Jacob Lifshay wrote:
> > On Tue, Jan 21, 2020, 02:42 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> > wrote:
> >
> >> https://libre-riscv.org/3d_gpu/arch_comparison/
> >
> > I added data for a lot more aspects. I think that we should go with
> > OpenPower due to several aspects:
> >
> > we should try to keep our messaging more consistent, continuously
> changing
> > which ISA we will use will cause people to not think we will ever
> complete
> > anything
>
> While I agree it may hurt the reputation a litttle, I think doing that
> should only be one small factor in the overall decision.


true.  oh.  also needed: whether the 3D-GPU or VPU acceleration depends on
those dependencies existing or not.  hmmm that's a 3 dimensional table,
whoops.

what i'm saying there is: for e.g. openrisc, do we *need* java, in order to
write the MESA library?  or pypy?

if llvm-or1k were to be modified to support a Simple-V-vectorised-or1k,
would we *need* to have java?

basically, what's the focus here? is it to *only* have a GPGPU with 3D and
Video (where userspace has to run RV64GC - unaccelerated, unmodified,
that's a given).

or, is it to drop in to a much better well-paved space (such as PowerPC)
where there's a bit more legs on it than even RISC-V let alone OpenRISC?

also, a quick review of or1k it is quirky.  mul goes into a special
register HI LO register that you have to extract from with followup ops (no
mulhu hsu etc). compares go into flag bits (more special regs).  making
those parallel and adding predication will be a pain.

in effect i am talking myself towards Power despire it having carry flags
as well.



> forums said about the project 2 years ago.  Plus this exercise of doing
> a detailed evaluation/comparison on the wiki means we can point
> detractors to this wiki page and say "Look!  We've done our due
> diligence, and can strongly justify why we've done what we've done,"
> regardless of the final decision


the other reason for the open discussion: if they didn't help, at the time,
then what gives people the right to complain? i have found this to be a
highly effective question.  put much nicer of course.


>
> Looking at the table now, I think no-JIT for V8 and Java are a big
> deal.  I suspect that V8/Chrome are very popular with the high volume
> customers we might get.  Infotainment systems in TVs/Cars/Planes are
> usually driven by some sort of WebUI or Android.


my point is that RV64GC can front for that and or1k only for the GPU/VPU

  So that's points for
> POWER.


yes a _full_ dual ISA one with more legs than RV is better, as jacob points
out


> None of them have Android support which is another high volume use
> case.


well what would the chances be that IBM would be interested in Android? vs
an OpenRISC backer.  and what progress has there been on android with RV?

 Our SoC is likely to be very popular with cheap android phones if
> we can get Android support, similar to the market MediaTek services but
> we have the advantage of being libre, which MediaTek is nowhere close
> to.


 oh good someone's done their research. relieved not to have to explain
Mediatek's systematic ongoing GPL violations.

 If we can guess which platform Google is more likely to add support
> for, that would be a useful input, but Google tends to be fairly
> unpredictable on what they will choose to focus on.


yehyeh.

l.




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