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.
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.
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.
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.
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 ;-)
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.
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
