On Wed, Apr 12, 2023 at 7:08 PM przemek klosowski via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> 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@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
