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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
