Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On 4/19/23 00:26, Benson Muite wrote: Probably each hardware vendor will need to become more involved in creating an RPM distribution for their use case and providing hardware for test builds. A single monolithic Fedora will not work. Having a subset of base packages would be very helpful. The rpm subarches might be a useful path, but then determining what you build for multiple of them and how needs to be addressed. The great thing about Linux is easy customisability. There may be a few RISC V variants that are widely used, but not clear which at present. The D1 chip is very affordable, and can have much use in education and IoT, though most support at present is available for Debian and OpenWRT. I certainly don't see Ventana taking that direction -- the market we've targeted isn't interested in a custom distro. In fact, they're very much of the mindset of using an existing distro. And seriously, who wants to recreate all the infrastructure necessary to build and support a system like Fedora or Ubuntu. That's a major investment with marginal value. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On 4/19/23 07:46, Florian Weimer wrote: * Jeff Law: Rather than trying to track all the individual extensions and combinations thereof, I would suggest focusing on RVI defined profiles. Essentially they provide a set of mandatory features the architecture must support (to be compliant with the profile). Do at least some of these profiles form an ascending chain? That's the plan as I understand it. *But* there are some chip vendors pushing back against some aspects of the profile plan, say for example requiring the vector extension. At least that's what I'm hearing through the grapevine. If it were up to me, I'd let them go their own way. If they don't see the value in conforming to a profile, then that's a choice they can make, but it'll restrict their ability to leverage all the work done at the distro level. Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On Wed, Apr 19, 2023 at 09:26:55AM +0300, Benson Muite wrote: > Probably each hardware vendor will need to become more involved in > creating an RPM distribution for their use case and providing hardware > for test builds. A single monolithic Fedora will not work. Having a > subset of base packages would be very helpful. This is the bad outcome IMHO. A 'downstream first' world. ;( But perhaps it's the future that waits us. > Maybe we need a RISC V sig? Like the one thats existed for the last few years? :) https://fedoraproject.org/wiki/Architectures/RISC-V kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
* Jeff Law: > Rather than trying to track all the individual extensions and > combinations thereof, I would suggest focusing on RVI defined > profiles. Essentially they provide a set of mandatory features the > architecture must support (to be compliant with the profile). Do at least some of these profiles form an ascending chain? Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On 4/15/23 19:56, Kevin Fenzi wrote: > On Sat, Apr 15, 2023 at 08:38:47AM -0600, Jeff Law wrote: >> >> >> On 4/15/23 00:10, David Abdurachmanov wrote: >> >> >>> >>> 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"). >> I think elsewhere you suggested treating the profile as the subarch for RPM. >> That may be a viable way to handle the SBC space. >> >> I still worry about supporting multiple profiles and would like to see a >> clear path to deprecating profiles that are out of date. The amount of pain >> I've seen in both the x86 and aarch worlds WRT baselines is something I'm >> keen to avoid repeating. > > Yeah, completely agreed. From an infrastructure standpoint, I would love > to get riscv in fedora as a primary arch, but I don't think it's > practical at all to bring in 3 or 4 or whatever subarches. There's just > no hardware that could actually keep up with mainline fedora currently > and the duplication of effort building 23,000 packages over N slightly > different subarches is not very tenable. > Probably each hardware vendor will need to become more involved in creating an RPM distribution for their use case and providing hardware for test builds. A single monolithic Fedora will not work. Having a subset of base packages would be very helpful. > The rpm subarches might be a useful path, but then determining what you > build for multiple of them and how needs to be addressed. > The great thing about Linux is easy customisability. There may be a few RISC V variants that are widely used, but not clear which at present. The D1 chip is very affordable, and can have much use in education and IoT, though most support at present is available for Debian and OpenWRT. Fedora probably seems to need more work for this. > I think we can point people to arm history and try and get them to not > repeat it (although perhaps it's too late for a lot of it). >>> >>> 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. > > Completely agree. > Maybe we need a RISC V sig? >>> 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. >> I'm sure folks will get this sorted out. My only concern with the syscall >> was to make sure the glibc folks were on board with using that to drive >> ifunc selection. It's a fairly different approach than has been taken in >> the past and I want to make sure it's not DOA for glibc. >> >> Once the kernel & glibc teams reach API agreement I think we'll be able to >> make a reasonable query about the system properties in multiple contexts, >> including the installer, rpm, etc. > > That would be great. > >>> 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. >> It'll get sorted out. We've got some bigger fish to fry WRT landing V >> support (if you've managed to avoid that mess, consider yourself lucky). >> >> Lots of stuff is backed up behind getting gcc-13 out the door so that gcc-14 >> development can open up. Not sure where profiles will fall into the >> priority list, it's hard to see past the V effort right now. > > Yep. And a lot of it is things that just need to mature and hardware > that needs to exist and code and... ;) But hopefully we will get there. > > kevin > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On Sat, Apr 15, 2023 at 08:38:47AM -0600, Jeff Law wrote: > > > On 4/15/23 00:10, David Abdurachmanov wrote: > > > > > > 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"). > I think elsewhere you suggested treating the profile as the subarch for RPM. > That may be a viable way to handle the SBC space. > > I still worry about supporting multiple profiles and would like to see a > clear path to deprecating profiles that are out of date. The amount of pain > I've seen in both the x86 and aarch worlds WRT baselines is something I'm > keen to avoid repeating. Yeah, completely agreed. From an infrastructure standpoint, I would love to get riscv in fedora as a primary arch, but I don't think it's practical at all to bring in 3 or 4 or whatever subarches. There's just no hardware that could actually keep up with mainline fedora currently and the duplication of effort building 23,000 packages over N slightly different subarches is not very tenable. The rpm subarches might be a useful path, but then determining what you build for multiple of them and how needs to be addressed. I think we can point people to arm history and try and get them to not repeat it (although perhaps it's too late for a lot of it). > > > > 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. Completely agree. > > 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. > I'm sure folks will get this sorted out. My only concern with the syscall > was to make sure the glibc folks were on board with using that to drive > ifunc selection. It's a fairly different approach than has been taken in > the past and I want to make sure it's not DOA for glibc. > > Once the kernel & glibc teams reach API agreement I think we'll be able to > make a reasonable query about the system properties in multiple contexts, > including the installer, rpm, etc. That would be great. > > 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. > It'll get sorted out. We've got some bigger fish to fry WRT landing V > support (if you've managed to avoid that mess, consider yourself lucky). > > Lots of stuff is backed up behind getting gcc-13 out the door so that gcc-14 > development can open up. Not sure where profiles will fall into the > priority list, it's hard to see past the V effort right now. Yep. And a lot of it is things that just need to mature and hardware that needs to exist and code and... ;) But hopefully we will get there. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On 4/15/23 00:25, David Abdurachmanov wrote: On Sat, Apr 15, 2023 at 7:08 AM Jeff Law wrote: On 4/14/23 20:14, Neal Gompa wrote: 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. Well, the RHEL direction was essentially mandated by the markets vendors were chasing. Plain and simple. You may say RHEL's ARM strategy was a mistake, but I'd disagree strongly. Fedora != CentOS Stream or/and RHEL. I am *well* aware. I wouldn't have brought RHEL into the discussion at all if Neal hadn't ;-) I am gonna repeat myself. I doubt there will be a need to support anything below RVA23 in CentOS Stream. That of course would mean that existing (or near future, yet to be announced) SBCs wouldn't be able to run it. Agreed. It's hard to see a case where anyone that wants Centos on RVA20. RVA23 is a much more realistic target. That's already happened. Stratification was inevitable given the RISC-V model. The only questions in my mind are viability in the server space and whether or not that could one day lead to offerings between server class and the SBC systems. Brings high-performance (and yet cheap) SBCs that it's fully compliant is too expensive today (i.e. you would lose money doing it [personal opinion]). It's going to happen, it's most likely coming from the Chinese market [personal opinion]. You're probably right on all those points. I could say that Ubuntu is the dominating distribution for RISCV SBCs. Canonical engineering resources and willingness to support pretty much every SBC (but with vendor kernel or/and firmware) is really hard to compete with. If you want to get the best out-of-the-box experience on your RISCV SBCs definitely Ubuntu is #1 suggestion, but that wasn't the case for many years. Ubuntu came to RISCV land very late (I would say somewhat recently), but now should be dominating (no way to confirm). Nice work by the Ubuntu community and Canonical engineers. They truly want to support every piece of hardware available out there. Agreed. And one can certainly question the sanity and business model of supporting all those SBCs. But if you look beyond the SBC space, Ubuntu has positioned themselves well to be the distro of choice for aspiring server platforms. One might even look at the SBC engagement as really just positioning themselves for the future (speculation on my part). Ubuntu may have come late, but they're engaged at a level that the Fedora community isn't even close to matching. Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On 4/15/23 00:10, David Abdurachmanov wrote: 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"). I think elsewhere you suggested treating the profile as the subarch for RPM. That may be a viable way to handle the SBC space. I still worry about supporting multiple profiles and would like to see a clear path to deprecating profiles that are out of date. The amount of pain I've seen in both the x86 and aarch worlds WRT baselines is something I'm keen to avoid repeating. 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. 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. I'm sure folks will get this sorted out. My only concern with the syscall was to make sure the glibc folks were on board with using that to drive ifunc selection. It's a fairly different approach than has been taken in the past and I want to make sure it's not DOA for glibc. Once the kernel & glibc teams reach API agreement I think we'll be able to make a reasonable query about the system properties in multiple contexts, including the installer, rpm, etc. 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. It'll get sorted out. We've got some bigger fish to fry WRT landing V support (if you've managed to avoid that mess, consider yourself lucky). Lots of stuff is backed up behind getting gcc-13 out the door so that gcc-14 development can open up. Not sure where profiles will fall into the priority list, it's hard to see past the V effort right now. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
Once upon a time, David Abdurachmanov said: > I would love to avoid supporting SBCs, especially as some of them are > really not suitable for feature rich Linux distributions. For me, my only interest in the foreseeable future for RISC-V would be SBCs, as an alternative to ARM (e.g. Raspberry Pi). It's not a matter of "afford" so much as there are hobbyist hardware projects and such that fit the SBC form rather than desktop/server form, and x86 has proved too expensive for that market (and failed just about every time it is tried). -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On Sat, Apr 15, 2023 at 7:08 AM Jeff Law wrote: > > > > On 4/14/23 20:14, Neal Gompa wrote: > > >> > > > > 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. > Well, the RHEL direction was essentially mandated by the markets vendors > were chasing. Plain and simple. You may say RHEL's ARM strategy was a > mistake, but I'd disagree strongly. Fedora != CentOS Stream or/and RHEL. Well, I have different opinions on what CentOS and RHEL should be/support in AArch64 days. CentOS Stream or/and RHEL is a different story, and shouldn't impact Fedora in exactly the same way. I am gonna repeat myself. I doubt there will be a need to support anything below RVA23 in CentOS Stream. That of course would mean that existing (or near future, yet to be announced) SBCs wouldn't be able to run it. > > > > > 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. > That's already happened. Stratification was inevitable given the RISC-V > model. The only questions in my mind are viability in the server space > and whether or not that could one day lead to offerings between server > class and the SBC systems. Brings high-performance (and yet cheap) SBCs that it's fully compliant is too expensive today (i.e. you would lose money doing it [personal opinion]). It's going to happen, it's most likely coming from the Chinese market [personal opinion]. > > > > > > 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. > The era where POWER was a viable platform outside the server space has > been gone for a long time. x86 just killed the market and it's not > clear there's space for anyone else in that market. Apple may prove me > wrong in that space, but the investment they've made is enormous. > > > > > > 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. > First mover advantage is already lost to Ubuntu. Sad but true in my > mind. Fedora has zero presence in the spaces that matter. The first distributions to support RISCV were Debian and Fedora. I even would say we worked together while building things out, or hunting firmware/silicon bugs. I am still on the Debian IRC channel, and some Debian folks are still on Fedora IRC channel. I could say that Ubuntu is the dominating distribution for RISCV SBCs. Canonical engineering resources and willingness to support pretty much every SBC (but with vendor kernel or/and firmware) is really hard to compete with. If you want to get the best out-of-the-box experience on your RISCV SBCs definitely Ubuntu is #1 suggestion, but that wasn't the case for many years. Ubuntu came to RISCV land very late (I would say somewhat recently), but now should be dominating (no way to confirm). Nice work by the Ubuntu community and Canonical engineers. They truly want to support every piece of hardware available out there. Cheers, david > > > > > > 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. > The current and future crop of SBCs just aren't going to have the oomph > to be a viable platform in my mind. I can take a 10+ year old xeon run > qemu on top of it and get dramatically better risc-v performance than > the SBCs out there > > Creating subarch around something like rv20, go ahead. But it's going > to be worse than the armv7 situation was. > > jeff > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines:
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On Sat, Apr 15, 2023 at 5:30 AM Neal Gompa wrote: > > On Fri, Apr 14, 2023 at 10:01 PM Jeff Law 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
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On Sat, Apr 15, 2023 at 5:01 AM Jeff Law 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. Remember that profiles are important for binaries that we ship, but the top level specification for the actual hardware systems will be RISCV Platforms. If you want to run Linux (especially enterprise level) you will implement that. Distributions will target a specific profile to support. > > > > > 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. They are, because that's what folks can afford for development, for their CI/CD pipelines, etc. I have seen the same situation in early ARMv8/AArch64 life. It was crazy expensive and hard to get systems. Even SiFive HiFive Unmatched is expensive for developers to invest in. I have heard that directly from the developers. > 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. It does. We (as a community and individuals) have to push for standards compliant SBCs and they should work the same way as a rack mount system. I wouldn't mind for CentOS Stream RISCV (and other rebuilds) not to support anything lower than RVA23 and fully standard compliant (once that happens). That's sane, but Fedora RISCV is in a different place. > > 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. Disclosure time. For folks that don't know me: - I have been building Fedora RISCV with Richard since ~2016. - I lead the current Fedora RISCV (fedora.riscv.rocks) efforts. - I worked for SiFive, and worked on some SBCs that you might know. - Today I work for Rivos (another RISCV startup). - Before I used to work at CERN and especially on ARMv8 64-bit/AArch64 craziness since early days. > > > > > > Still, it would be neat if there was a good technical solution for > > subarchitecture diversity because there will be more of it in the > > future. Jim Keller, the prolific CPU designer who worked on DEC Alpha, > > AMD K7 and Zen, Intel, Tesla, and Apple, has an interesting talk where > > he justifies going to RISC-V architecture because it is so much easier > > to extend it for high performance on specific tasks: > The fragmentation will kill RISC-V from a distro standpoint if it's not > brought under control -- and I had that position well before I joined > the RISC-V world. Profiles are a step, but by no means a complete > solution. Distros are terrible at supporting ISA customizations. Fragmentation issue on RISC-V is a bigger problem than in ARM land. Profiles are trying to help here, but true, it's not a solution on its own. Cheers, david > > heff > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On Sat, Apr 15, 2023 at 4:49 AM Jeff Law wrote: > > > > On 4/12/23 10:57, David Abdurachmanov wrote: > > > > > We have been focusing and building for RV64GC, which is kinda > > represented by the RVA20 profile. RVA20 is considered a major profile, > > but it significantly lacks modern ISA extensions. There is also RVA22, > > which is considered a "minor" profile. The next "major" one will be > > RVA23. RVA23 will be a true start for RISCV (especially entering the > > high-performance market). > > My sense is RVA23 is likely also going to be considered a minor profile, > for better or worse. RVA24 might be a better target. I wouldn't be surprised. RVA23 exists mainly because a large number of specifications/extensions didn't manage to land before 2022. The original idea was to do it every 2 years. Now it's more like every year, but some are minor and some are major. There is low (or none) expectation that Linux distributions (or other OSes) will support minor profiles (or at least it was the case some time ago; things are changing constantly). > > > > Profiles are important for the binaries we > > ship, but there is more. The most top-level specification that we will > > target is RISCV Platforms (defines also non-ISA stuff), which is > > currently blocked by a number of other WIP specifications. Right now > > the base for that is RVA22, but I would be surprised that the final > > version of it will require RVA23 (just a speculation at this point). > > > > Thus in the future we want to support platforms that properly > > implement and comply with RISCV Platforms specifications. There will > > probably be a compliance test suite at some point too. > > > > All the SoCs/SBCs available (or soon to be available on the market) > > are still RVA20 / RV64GC + not-ratified versions of RVI extension > > or/and vendor extensions. > Yea, but I'm not sure we want to focus on the SBCs. They're woefully > underpowered and we'll end up leaving a notable amount of performance on > the table for the beefier systems that are coming online. RVA22 would > be a better target in my mind. I would love to avoid supporting SBCs, especially as some of them are really not suitable for feature rich Linux distributions. Every time I talk to SoC/IP/SBCs makers I ask them to align their future products to RVI standards, incl. profiles and platforms (once that happens). I do want SBCs with a reasonable price point to work/act the same way as a large system in a rack, but it's a highly naive way of thinking (I understand that). It's not likely to happen, but we can still push for it. We cannot avoid SBCs, because that's mostly what users and developers will be able to afford. I had explicitly private messages on Matrix and IRC regarding supporting one or another SBC, or to keep supporting them. > > WRT compliance tests. Those are still pretty weak at this point IMHO, > and while I see signs of improvement, it's agonizingly slow. I wouldn't > expect much in that space in the timeframes that matter for the > decisions we need to be making. We have been building Fedora RISCV since ~2016, and I fully understand a slow and painful life :) > > > > > > > My preference would be to (in short): > > - Do not change the baseline. That is "riscv64" is RVA20 / RV64GC. > > This means that existing hardware is supported for a good amount of > > time. > > - Introduce RVA20 / RVA22 / RVA23 arch strings (blocked by "hw probe" > > syscall landing in Linux kernel [most likely 6.4 or 6.5 kernel]). > > - Skip RVA22 as it's a stop-gap solution and considered as a "minor" > > ISA profile. > > - Profile a full RVA23 Fedora/RISCV rebuild (i.e. different arch > > repository). > > - Review policies for 3rd party repositories (i.e. vendor > > repositories)., DNF, vendor lock, consider enabling vendor lock by > > default (already supported by DNF in most commands, but vendor lock is > > not on by default). > That's not too bad. Essentially you're suggesting we stick to RVA20 > until RVA23 is available, then we make the switch. I could support > that, though I fear the screaming when we do make the switch to RVA23 > and leave some folks behind. Not exactly, but that's a discussion topic. I have seen previous discussions on x86_64 baseline v2/v3/v4 on this mailing-list, and I have been talking to various Fedora RISCV users for years. I don't want to prematurely change the "riscv64" baseline, but that simply makes folks angry. Also those discussions typically tend to generate a large number of emails with no resolution. My idea is to hop on the RVI RISCV Profiles train. That means we support major RISCV Profiles (and minor if there is enough resources or/and funding my companies). Today that would mean RVA20 (major), RVA22 (minor), RVA23 (major). Where riscv64 today and for the foreseeable future is RVA20. So let's say we introduce new RPM arches (similar to how things were done for x86_64 v2/v3/v4 a couple months ago). I would prefer not to use
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On 4/14/23 20:14, Neal Gompa wrote: 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. Well, the RHEL direction was essentially mandated by the markets vendors were chasing. Plain and simple. You may say RHEL's ARM strategy was a mistake, but I'd disagree strongly. 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. That's already happened. Stratification was inevitable given the RISC-V model. The only questions in my mind are viability in the server space and whether or not that could one day lead to offerings between server class and the SBC systems. 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. The era where POWER was a viable platform outside the server space has been gone for a long time. x86 just killed the market and it's not clear there's space for anyone else in that market. Apple may prove me wrong in that space, but the investment they've made is enormous. 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. First mover advantage is already lost to Ubuntu. Sad but true in my mind. Fedora has zero presence in the spaces that matter. 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. The current and future crop of SBCs just aren't going to have the oomph to be a viable platform in my mind. I can take a 10+ year old xeon run qemu on top of it and get dramatically better risc-v performance than the SBCs out there Creating subarch around something like rv20, go ahead. But it's going to be worse than the armv7 situation was. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On Fri, Apr 14, 2023 at 10:01 PM Jeff Law 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 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. 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. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
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. Still, it would be neat if there was a good technical solution for subarchitecture diversity because there will be more of it in the future. Jim Keller, the prolific CPU designer who worked on DEC Alpha, AMD K7 and Zen, Intel, Tesla, and Apple, has an interesting talk where he justifies going to RISC-V architecture because it is so much easier to extend it for high performance on specific tasks: The fragmentation will kill RISC-V from a distro standpoint if it's not brought under control -- and I had that position well before I joined the RISC-V world. Profiles are a step, but by no means a complete solution. Distros are terrible at supporting ISA customizations. heff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On 4/12/23 10:57, David Abdurachmanov wrote:
We have been focusing and building for RV64GC, which is kinda
represented by the RVA20 profile. RVA20 is considered a major profile,
but it significantly lacks modern ISA extensions. There is also RVA22,
which is considered a "minor" profile. The next "major" one will be
RVA23. RVA23 will be a true start for RISCV (especially entering the
high-performance market).
My sense is RVA23 is likely also going to be considered a minor profile,
for better or worse. RVA24 might be a better target.
Profiles are important for the binaries we
ship, but there is more. The most top-level specification that we will
target is RISCV Platforms (defines also non-ISA stuff), which is
currently blocked by a number of other WIP specifications. Right now
the base for that is RVA22, but I would be surprised that the final
version of it will require RVA23 (just a speculation at this point).
Thus in the future we want to support platforms that properly
implement and comply with RISCV Platforms specifications. There will
probably be a compliance test suite at some point too.
All the SoCs/SBCs available (or soon to be available on the market)
are still RVA20 / RV64GC + not-ratified versions of RVI extension
or/and vendor extensions.
Yea, but I'm not sure we want to focus on the SBCs. They're woefully
underpowered and we'll end up leaving a notable amount of performance on
the table for the beefier systems that are coming online. RVA22 would
be a better target in my mind.
WRT compliance tests. Those are still pretty weak at this point IMHO,
and while I see signs of improvement, it's agonizingly slow. I wouldn't
expect much in that space in the timeframes that matter for the
decisions we need to be making.
My preference would be to (in short):
- Do not change the baseline. That is "riscv64" is RVA20 / RV64GC.
This means that existing hardware is supported for a good amount of
time.
- Introduce RVA20 / RVA22 / RVA23 arch strings (blocked by "hw probe"
syscall landing in Linux kernel [most likely 6.4 or 6.5 kernel]).
- Skip RVA22 as it's a stop-gap solution and considered as a "minor"
ISA profile.
- Profile a full RVA23 Fedora/RISCV rebuild (i.e. different arch repository).
- Review policies for 3rd party repositories (i.e. vendor
repositories)., DNF, vendor lock, consider enabling vendor lock by
default (already supported by DNF in most commands, but vendor lock is
not on by default).
That's not too bad. Essentially you're suggesting we stick to RVA20
until RVA23 is available, then we make the switch. I could support
that, though I fear the screaming when we do make the switch to RVA23
and leave some folks behind.
Here is a thing. You don't want to run RVA20 binaries on top of RVA23
hardware. You most likely will lose tons of performance. It will not
be something like running x86_64 baseline on top of x86_64-{v3,v4}
hardware where applications get 3%, 5%, 10% in some very specific
workloads a bit more. IIRC bit-manip alone can deliver significant
performance improvements. I think there are ~130 extensions right now,
and there are another ~50 in the pipeline right now.
Exactly. And while there may be ~130 extensions, many just don't
matter. Don't tell the relevant folks I said that ;-)
We can use glibc-hwcaps, and have a small predefined list of packages
(probably max a few hundreds), but that doesn't apply to the binaries,
just loadable libraries.
The set should be *very* small. glibc and perhaps openssl are worth
implementing dynamic dispatch. The rest I wouldn't bother. The QE
overhead of testing gets out of hand quickly. We're better off getting
to a good profile to set the floor at a reasonable place.
RVA20 isn't that reasonable place. One could even claim that anything
without V isn't reasonable in the modern world.
jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On Wed, Apr 12, 2023 at 7:08 PM przemek klosowski via devel
wrote:
>
>
> On 4/11/23 22:08, Jeff Law wrote:
> > On 4/11/23 19:14, przemek klosowski via devel wrote:
> >> The situation in the RISC-V universe is even more complicated because
> >> of all the extensions
> >>
> >> ...
> >> Whatever standard scheme Fedora uses for x86 will hopefully be very
> >> useful for RiSC-V era that is apparently coming, with Linux-capable
> >> SBC boards like VisionFive ($65) and Pine64 ($70 and $8 (!) ox64)
> >> just becoming available, and a lot of activity on the horizon.
> > Rather than trying to track all the individual extensions and
> > combinations thereof, I would suggest focusing on RVI defined
> > profiles. Essentially they provide a set of mandatory features the
> > architecture must support (to be compliant with the profile).
> >
> > 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 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).
Here is my take on this.
We have been focusing and building for RV64GC, which is kinda
represented by the RVA20 profile. RVA20 is considered a major profile,
but it significantly lacks modern ISA extensions. There is also RVA22,
which is considered a "minor" profile. The next "major" one will be
RVA23. RVA23 will be a true start for RISCV (especially entering the
high-performance market). Profiles are important for the binaries we
ship, but there is more. The most top-level specification that we will
target is RISCV Platforms (defines also non-ISA stuff), which is
currently blocked by a number of other WIP specifications. Right now
the base for that is RVA22, but I would be surprised that the final
version of it will require RVA23 (just a speculation at this point).
Thus in the future we want to support platforms that properly
implement and comply with RISCV Platforms specifications. There will
probably be a compliance test suite at some point too.
All the SoCs/SBCs available (or soon to be available on the market)
are still RVA20 / RV64GC + not-ratified versions of RVI extension
or/and vendor extensions.
>
> Still, it would be neat if there was a good technical solution for
> subarchitecture diversity because there will be more of it in the
> future. Jim Keller, the prolific CPU designer who worked on DEC Alpha,
> AMD K7 and Zen, Intel, Tesla, and Apple, has an interesting talk where
> he justifies going to RISC-V architecture because it is so much easier
> to extend it for high performance on specific tasks:
>
> https://youtu.be/yHrdEcsr9V0?t=297
>
> Currently we have a wide variety of approaches, from recompiling for the
> specific subarchitecture a la Arch to runtime codepath selection in fat
> binaries, so I'm glad that people are thinking about the relative merits
> of those and trying to figure out if there's a common best approach.
My preference would be to (in short):
- Do not change the baseline. That is "riscv64" is RVA20 / RV64GC.
This means that existing hardware is supported for a good amount of
time.
- Introduce RVA20 / RVA22 / RVA23 arch strings (blocked by "hw probe"
syscall landing in Linux kernel [most likely 6.4 or 6.5 kernel]).
- Skip RVA22 as it's a stop-gap solution and considered as a "minor"
ISA profile.
- Profile a full RVA23 Fedora/RISCV rebuild (i.e. different arch repository).
- Review policies for 3rd party repositories (i.e. vendor
repositories)., DNF, vendor lock, consider enabling vendor lock by
default (already supported by DNF in most commands, but vendor lock is
not on by default).
Here is a thing. You don't want to run RVA20 binaries on top of RVA23
hardware. You most likely will lose tons of performance. It will not
be something like running x86_64 baseline on top of x86_64-{v3,v4}
hardware where applications get 3%, 5%, 10% in some very specific
workloads a bit more. IIRC bit-manip alone can deliver significant
performance improvements. I think there are ~130 extensions right now,
and there are another ~50 in the pipeline right now.
We can use glibc-hwcaps, and have a small predefined list of packages
(probably max a few hundreds), but that doesn't apply to the binaries,
just loadable libraries.
Cheers,
david
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On 4/11/23 22:08, Jeff Law wrote: On 4/11/23 19:14, przemek klosowski via devel wrote: The situation in the RISC-V universe is even more complicated because of all the extensions ... Whatever standard scheme Fedora uses for x86 will hopefully be very useful for RiSC-V era that is apparently coming, with Linux-capable SBC boards like VisionFive ($65) and Pine64 ($70 and $8 (!) ox64) just becoming available, and a lot of activity on the horizon. Rather than trying to track all the individual extensions and combinations thereof, I would suggest focusing on RVI defined profiles. Essentially they provide a set of mandatory features the architecture must support (to be compliant with the profile). 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 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). Still, it would be neat if there was a good technical solution for subarchitecture diversity because there will be more of it in the future. Jim Keller, the prolific CPU designer who worked on DEC Alpha, AMD K7 and Zen, Intel, Tesla, and Apple, has an interesting talk where he justifies going to RISC-V architecture because it is so much easier to extend it for high performance on specific tasks: https://youtu.be/yHrdEcsr9V0?t=297 Currently we have a wide variety of approaches, from recompiling for the specific subarchitecture a la Arch to runtime codepath selection in fat binaries, so I'm glad that people are thinking about the relative merits of those and trying to figure out if there's a common best approach. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On 4/11/23 19:14, przemek klosowski via devel wrote: On 4/4/23 10:28, Dan Čermák wrote: Chris Adams writes: Yeah, it'd be back to the i386/i586/i686 days... which was a bit of a PITA sometimes. But cramming multiple architectures of core libraries into a single RPM would be bad for disk space, image size, downloads, etc. But something that didn't exist in the i386/i686 days is containers - whether base images like for podman or full things like Flatpaks. Before going too deep into multi-level architectures, that should be taken into account. Afaik at least container runtimes do not support really support x86_64 subarchitectures: https://github.com/containers/podman/discussions/15256 The situation in the RISC-V universe is even more complicated because of all the extensions https://en.wikichip.org/wiki/risc-v/standard_extensions It'll be challenging to write and package software that is portable between all those variants---the fat binaries are just not practical due to combinatorial complexity, so it'll have to be either install-time or link-time configuration. Whatever standard scheme Fedora uses for x86 will hopefully be very useful for RiSC-V era that is apparently coming, with Linux-capable SBC boards like VisionFive ($65) and Pine64 ($70 and $8 (!) ox64) just becoming available, and a lot of activity on the horizon. Rather than trying to track all the individual extensions and combinations thereof, I would suggest focusing on RVI defined profiles. Essentially they provide a set of mandatory features the architecture must support (to be compliant with the profile). 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. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)
On 4/4/23 10:28, Dan Čermák wrote: Chris Adams writes: Yeah, it'd be back to the i386/i586/i686 days... which was a bit of a PITA sometimes. But cramming multiple architectures of core libraries into a single RPM would be bad for disk space, image size, downloads, etc. But something that didn't exist in the i386/i686 days is containers - whether base images like for podman or full things like Flatpaks. Before going too deep into multi-level architectures, that should be taken into account. Afaik at least container runtimes do not support really support x86_64 subarchitectures: https://github.com/containers/podman/discussions/15256 The situation in the RISC-V universe is even more complicated because of all the extensions https://en.wikichip.org/wiki/risc-v/standard_extensions It'll be challenging to write and package software that is portable between all those variants---the fat binaries are just not practical due to combinatorial complexity, so it'll have to be either install-time or link-time configuration. Whatever standard scheme Fedora uses for x86 will hopefully be very useful for RiSC-V era that is apparently coming, with Linux-capable SBC boards like VisionFive ($65) and Pine64 ($70 and $8 (!) ox64) just becoming available, and a lot of activity on the horizon. https://www.reddit.com/r/RISCV/comments/11wdk2i/riscv_linux_sbcs_how_are_we_doing/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
