On Sat, Apr 15, 2023 at 5:30 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Fri, Apr 14, 2023 at 10:01 PM Jeff Law <jeffreyalaw@xxxxxxxxx> wrote: > > > > > > > > On 4/12/23 10:08, przemek klosowski via devel wrote: > > >> > > >> That may rule out certain processors, but it ultimately provides a > > >> higher performing baseline architecture for systems that are > > >> (hopefully) going to be good performing parts rather than embedded > > >> focused parts. > > > > > > Yes, good point, but there's already a number of profiles even though > > > they are barely out of the gate: > > > > > > https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc > > I know. While I'm not involved in setting the profiles, I do get > > briefed on them reasonably often. > > > > > > > > I of course agree with you that it makes sense to focus support on a > > > small number of existing platforms with good reputation and performance > > > (for instance both VisionFive and Pine64 are based on StarFive JH7110 SoC). > > Those are not particularly interesting in my mind for a distro target. > > If it can't run a performant system I'd put on my desk or in my rack, > > then it's an embedded target in my mind (yes, I'm over-generalizing). > > There's a place for those, but I don't think that should be Fedora's > > focus for RISC-V. > > > > Full disclosure. I work for Ventana and have a long history with Red > > Hat and Fedora. My vision for Fedora going back before it was actually > > launched as for a desktop/developer focused distribution similar to RHL, > > but free -- and as a feeder distribution into what was then known as > > Advanced Server, now RHEL. > > > > We should not screw up with RISC-V in Fedora like RHEL did with ARM. > Yes, I'm saying RHEL's ARM strategy was a mistake, and still is, to > some degree. We see aspects of this being walked back now as the > ecosystem didn't go the way RHEL ARM folks hoped, and breaking further > into that ecosystem requires reversing some of those choices. We > should learn from that for Fedora RISC-V. > > Like ARM, RISC-V risks (pun intended!) total stratification between > low/mid range SBCs and unobtanium servers. Given the current path of the > groups working in RISC-V, this is certain to happen. Thus, if Fedora > RISC-V cannot run well on RISC-V SBCs, then we effectively have no > useful RISC-V port, since nobody can use it. We are making the same (or similar) mistakes with RISCV as ARM. A long time ago I assumed this would not be the case. After working on this for years now, I think, this is something you cannot avoid. It's just "growing pains". A proper transition from pre-standards/compliance mess will take years too (probably less than a decade). We have to support SCBs as-is. We even have 64-core OoO (and even dual-socket 128-core) systems coming that are still RVA20 (what I call "a large scale SBC trying to be a server"). But Fedora RISCV as-is is not how future Fedora RISCV should be. The future is RVA23 (or beyond) and standard compliance. There will be significant performance differences between profiles for some time. Especially RVA20 -> RVA23. RVA20 (or RVA64GC) is just way too small with lack of modern ISA. We have had a toy for ~10 years now, and now we are moving toward high-performance servers, even HPC, Android (see latest Google announcements), etc. That's not driven by RVA20. That's RVA23 (and beyond) + vendor extensions. > > We already have similar problems with POWER (ppc64le) and Z (s390x), > but the former was built in an era when there were computers of > reasonable performance across all price points. The latter is > basically funded by IBM development and nobody can really do anything > with it. > > For the first time in a long time, Fedora has the opportunity to have > a first-mover advantage and become the default platform for hobbyist, > professional, and high-end systems of an architecture. Let's not > squander it on myopic views of datacenter class hardware that don't > exist yet leveraging specifications that nobody is implementing in > currently available hardware. SiFive P670 and XuanTie C908 (Alibaba T-HEAD) are already RVA22 compatible. It's typically years before IP announcement and actual physical product in your hands. But again, RVA22 is minor (it's just a stop-gap, snaphot), and true interest is RVA23 (and beyond). RVA20/RV64GC is to stay here for years to come. We should continue to support that, but we shouldn't be blocked by that and only support it. We need to hop on the RVI Profiles train model. > > Insofar as subarches go, let's just define them in RPM like we have > for 32-bit x86 and more recently 64-bit x86. If we know what kind of > ISA profiles are out there, we should just incorporate them into RPM > and set up the compatibility detection logic for them to work. Yes! Blocked by lack of "hw probe" interface. There will be "hw probe" syscall for RISCV, in v6.4 and v6.5 kernel (I hope). We don't have cpuid instruction, HWCAP is way too small for all the extensions available. Once that is available we can wire detection in RPM (not sure if that actual logic should be directly written in RPM, or as a separate library). I would suggest "rva20", "rva22", "rva23" as new arch strings. Where "riscv64" is equal to "rva20". Note that toolchains don't accept RISCV Profiles yet, but that has been under discussion for quite some time already. I would assume starting GCC 14 timeframe all of that should work. Cheers, david > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
