On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote: Handy! Could you explain more what this means, exactly? I may have cried a little bit in joy here. This is huge! This could be a real winner for glibc, texlive and fedora-release. Could you provide more info on this? It's written almost like a side-note, but this could be a big deal. But I want it now... <petulant pout>

On 3/31/23 15:40, Stephen Gallagher wrote: No! But here is the commit: https://github.com/rpm-software-management/rpm/commit/cd46c1704ccd8eeb9b6... It looks like it adds x86_64_v2, x86_64_v3 and x86_64_v4. Something about some x86_64 processors having additional capabilities. There now is proper documentation online. This just got merged, so it wasn't available yet, when I submitted the change page. https://rpm-software-management.github.io/rpm/manual/users_and_groups.html Note that this will not be enabled fully at first. There needs to be another Global Change to enable this fully. The actual update of RPM is meant to be as little disruptive as possible. After the update the new features can be enabled or put into Packaging Policy. But I guess most here know that dance already. Yes. But this was actually meant to be used for whole ecosystems like Python to turn Manifest files into sub packages. Well this was done as a prove of concept for the Dynamic Spec feature. See https://github.com/rpm-software-management/rpm/pull/2300 for the change itself For packagers all they need to know that there is a new --generate-subpackages parameter for find-lang.sh that creates sub packages according to the %_langpack_template macro. This could probably use a bit more review from people more into i18n than myself. The time will come. The time will come. Florian

On Sun, Apr 2, 2023 at 5:37 PM Mattia Verga via devel <devel(a)lists.fedoraproject.org&gt; wrote: I don't think we can drop i686 as long as we need to support at least a subset of i686 for wine / steam / $your favourite 32-bit only third-party application. Additionally, I don't think building x86_64-v2 / x86_64-v3 / x86_64-v4 variants of *all* packages that are built on x86_64 makes sense. Some packages already have runtime detection of available CPU features and will choose the fastest path without having to be compiled for it explicitly. Other libraries will not really benefit from newer x86_64 instructions. But there are some libraries that *would* benefit quite a bit, and we could look into whether it's possible to optionally build additional versions of these select packages. As far as I know, this is also the approach that OpenSUSE has chosen. Fabio

On 02/04/2023 17:36, Mattia Verga via devel wrote: AVX2 can bring a huge performance boost. -- Sincerely, Vitaly Zaitsev (vitaly(a)easycoding.org)

On Sun, Apr 02, 2023 at 09:54:04PM +0200, Dan Čermák wrote: This is very … underwhelming. x86-64-v2 is essentially identical to x86-64-v1. x86-64-v3 is better. It even shows speed-ups of 20%, but only with -Ofast. And -Ofast is not something that can be enabled as a default build flag, because it leads to surprising and unpredictable behaviour in some cases. (*) At -O2, which we use, the speed up is maybe 10%. Yeah, I think that's the way to go. I think we should identify 100 shared libraries which would be positively impacted by x86-64-v3 and provide a -v3 subrpm for them. This would be a nice feature for F40. Zbyszek

On Tue, Apr 04, 2023 at 11:02:53AM +0200, Florian Weimer wrote: I had something different in mind: -Ofast implies -ffast-math which implies -ffinite-math-only, i.e. no NaNs or Infs in floating point calculations (and other effects). https://simonbyrne.github.io/notes/fastmath/ Zbyszek

On Tue, Apr 04, 2023 at 11:17:50AM +0200, Jakub Jelinek wrote: If we start compiling libaries twice, it'd double the package sizes (or actually more than double, since in the benchmarks the code size with -v3 is also increased slightly). I assume people would want to get the optimized form split out to a subpackage so people who don't use this, don't pay the price. If we use the new "dynamic subpackages" feature of RPM, and some smart macros, this could even not be a big packaging burden. Zbyszek

On Tue, Apr 04, 2023 at 09:05:43AM -0400, Stephen Smoogen wrote: Yes, exactly. The cost is clear, the benefit less so. My thinking was to figure out the packages where there's actually a measureable tangible benefit, and only do this there. For example, vorbis, flac, zstd benefit 5–20% in [1]. [1] https://sunnyflunk.github.io/2023/01/15/x86-64-v3-Mixed-Bag-of-Performanc...

Chris Adams <linux(a)cmadams.net&gt; writes: Afaik at least container runtimes do not support really support x86_64 subarchitectures: https://github.com/containers/podman/discussions/15256 Cheers, Dan

On 4/11/23 19:14, przemek klosowski via devel wrote: 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. jeff

On Wed, Apr 12, 2023 at 7:08 PM przemek klosowski via devel <devel(a)lists.fedoraproject.org&gt; wrote: Here is my take on this. 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). 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. 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). 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. 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. Cheers, david > _______________________________________________ > devel mailing list -- devel(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)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

On Sat, Apr 15, 2023 at 4:49 AM Jeff Law <jeffreyalaw(a)gmail.com&gt; wrote: 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). 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. We have been building Fedora RISCV since ~2016, and I fully understand a slow and painful life :) 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). Yeah. There are way too many of them to even keep track. 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

On 4/12/23 10:08, przemek klosowski via devel wrote: I know. While I'm not involved in setting the profiles, I do get briefed on them reasonably often. Those are not particularly interesting in my mind for a distro target. If it can't run a performant system I'd put on my desk or in my rack, then it's an embedded target in my mind (yes, I'm over-generalizing). There's a place for those, but I don't think that should be Fedora's focus for RISC-V. Full disclosure. I work for Ventana and have a long history with Red Hat and Fedora. My vision for Fedora going back before it was actually launched as for a desktop/developer focused distribution similar to RHL, but free -- and as a feeder distribution into what was then known as Advanced Server, now RHEL. The fragmentation will kill RISC-V from a distro standpoint if it's not brought under control -- and I had that position well before I joined the RISC-V world. Profiles are a step, but by no means a complete solution. Distros are terrible at supporting ISA customizations. heff

On 4/14/23 20:14, Neal Gompa wrote: Well, the RHEL direction was essentially mandated by the markets vendors were chasing. Plain and simple. You may say RHEL's ARM strategy was a mistake, but I'd disagree strongly. That's already happened. Stratification was inevitable given the RISC-V model. The only questions in my mind are viability in the server space and whether or not that could one day lead to offerings between server class and the SBC systems. The era where POWER was a viable platform outside the server space has been gone for a long time. x86 just killed the market and it's not clear there's space for anyone else in that market. Apple may prove me wrong in that space, but the investment they've made is enormous. First mover advantage is already lost to Ubuntu. Sad but true in my mind. Fedora has zero presence in the spaces that matter. The current and future crop of SBCs just aren't going to have the oomph to be a viable platform in my mind. I can take a 10+ year old xeon run qemu on top of it and get dramatically better risc-v performance than the SBCs out there Creating subarch around something like rv20, go ahead. But it's going to be worse than the armv7 situation was. jeff

On 4/15/23 00:25, David Abdurachmanov wrote: I am *well* aware. I wouldn't have brought RHEL into the discussion at all if Neal hadn't ;-) Agreed. It's hard to see a case where anyone that wants Centos on RVA20. RVA23 is a much more realistic target. You're probably right on all those points. Agreed. And one can certainly question the sanity and business model of supporting all those SBCs. But if you look beyond the SBC space, Ubuntu has positioned themselves well to be the distro of choice for aspiring server platforms. One might even look at the SBC engagement as really just positioning themselves for the future (speculation on my part). Ubuntu may have come late, but they're engaged at a level that the Fedora community isn't even close to matching. Jeff

On 4/15/23 00:10, David Abdurachmanov wrote: 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. 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. 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

On 4/15/23 19:56, Kevin Fenzi wrote: Probably each hardware vendor will need to become more involved in creating an RPM distribution for their use case and providing hardware for test builds. A single monolithic Fedora will not work. Having a subset of base packages would be very helpful. The great thing about Linux is easy customisability. There may be a few RISC V variants that are widely used, but not clear which at present. The D1 chip is very affordable, and can have much use in education and IoT, though most support at present is available for Debian and OpenWRT. Fedora probably seems to need more work for this. Maybe we need a RISC V sig? >>> 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 > >

On 4/19/23 00:26, Benson Muite wrote: I certainly don't see Ventana taking that direction -- the market we've targeted isn't interested in a custom distro. In fact, they're very much of the mindset of using an existing distro. And seriously, who wants to recreate all the infrastructure necessary to build and support a system like Fedora or Ubuntu. That's a major investment with marginal value. jeff

* Jeff Law: Do at least some of these profiles form an ascending chain? Thanks, Florian

On Tue, Apr 4, 2023 at 3:38 AM Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl&gt; wrote: This is further confirmed by Arch's data that even x86_64-v3 isn't necessarily great either: https://sunnyflunk.github.io/2023/01/15/x86-64-v3-Mixed-Bag-of-Performanc... It seems that moving to -O3 would provide more gains than x86_64-v3. Otherwise, the only thing you really get from moving subarches is breaking lots of hardware. -- 真実はいつも一つ！/ Always, there's only one truth!

On 04/04/2023 11:17, Neal Gompa wrote: AVX2 can significantly boost the performance of modern processors in SIMD operations. -- Sincerely, Vitaly Zaitsev (vitaly(a)easycoding.org)

On 04/04/2023 15:15, Neal Gompa wrote: Web browsers, game engines, audio/video editing software. -- Sincerely, Vitaly Zaitsev (vitaly(a)easycoding.org)

V Tue, Apr 04, 2023 at 07:37:59AM +0000, Zbigniew Jędrzejewski-Szmek napsal(a): You can start with packages which already compile with -march=x86-64-v3 and thus crash on a generic hardware Fedora is supposed to support. E.g. cryptlib <https://bugzilla.redhat.com/show_bug.cgi?id=2182688>;. -- Petr

On 4/3/23 08:04, Florian Weimer wrote: These are not independent architectures but are compatible with all lower ones. So it is similar to i386, i486, i586, i686 - just this time in 64 bit. They are there to allow distributions to create optimized packages that only run on processors with the additional features.

https://github.com/rpm-software-management/rpm/releases/tag/rpm-4.19.0-al... 5 days ago.