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@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