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