On Sat, Apr 15, 2023 at 4:49 AM Jeff Law <jeffreya...@gmail.com> 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 glibc-hwcaps as I don't trust us (community
in general) yet avoiding some kind of psABI issues, especially as
vector extensions are arriving. Historically RVI made mistakes with
RISCV standard compatibility, and we still have missing bits in psABI
(and other places). GCC and LLVM/Clang still do different things in
some corner cases IIRC. Simply put, things aren't aligned yet. Thus
not mixing RVA20 + glibc-hwcaps (RVA22, RVA23) binaries would allow to
avoid potential psABI issues (i.e. makes life easier). Also in that
case we don't need to work on Fedora infra side, package manager
components, etc. to handle this complicated situation.
RVA20 and RVA23 (and maybe RVA22, but again most companies should/will
skip it) are completely different repositories. Fully optimized
(binaries and shared libraries). Let's say Fedora installer could
detect your hardware capabilities (incl. a RISCV profile), and if
anything above RVA20 (default) is detected the user could switch to
install RVA22, RVA23, RVA24, etc.
I would like to remind you that today RVI doesn't tell how long a
particular profile will stay compatible with the future. That is, you
shouldn't expect RVA20 to run on RVA35 or something like that. RVI
wants (or at least some raised this on RVI mailing lists)
obsolete/sunset extensions with time if there is a better alternative.
There is a different story for optional extensions part of a
particular profile. For example RVA22 had scalar crypto extensions as
optional extensions, but they were removed in RVA23 as vector is now
mandatory.
Note1: You can still use extensions if they don't break compatibility
with profile.
Note2: It's just an example on how newer/better ISA extensions
deprecates some older ISA extensions.
TL;DR We cannot sit on RVA20 for another 10 or 20 years. It already
has 10+ years on it. RISC-V Platforms specifications most likely will
require RVA23 (or RVA22, or something newer).
>
>
> >
> > 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 ;-)
Yeah. There are way too many of them to even keep track.
>
>
> >
> > 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.
I agree that RVA20 is a bad choice to stay, but the majority of Fedora
RISCV users and developers can afford it for the next few years.
RVA23 (or newer) will be unobtainium for the majority of folks (inlc.
developers; unless you work for the companies that will acquire it for
you). That's a problem, and I have been telling that to folks in the
industry for years.
Cheers,
david
>
>
>
>
>
> 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
