<davidlt[m]>
They still don't provide details what they have on their core IP.
<davidlt[m]>
We know they have at least one vendor extension which is now pretty much RVI extension.
<davidlt[m]>
Anyways I don't expect to get my hands on one of these for quite some time. 😢
zsun has joined #fedora-riscv
zsun has quit [Client Quit]
jcajka has quit [Quit: Leaving]
<djdelorie>
davidlt[m]: I plan on pushing back on any attempt to add environment variable controls to glibc. Yes, tunables is the mechanism to use
davidlt has joined #fedora-riscv
<davidlt[m]>
djdelorie: that's good to know. I don't there is anything like this in glibc already (I didn't check now).
<davidlt[m]>
Realistically I would prefer this not to land until we can agree on the feature probe interface.
<davidlt[m]>
Without that an agreement on tunables would be fine, because those will exist independently from how we acquire machine features.
<davidlt[m]>
Now that profiles are finally becoming a thing, hardware is coming out with extensions too a lot of things will explode :)
<djdelorie>
it's arm all over again, which I predicted at the start...
<davidlt[m]>
djdelorie: what else did you expect? :)
<djdelorie>
I expected it. I also warned against it.
<davidlt[m]>
Well. After many years I understood that it's impossible to avoid having growing pains.
<djdelorie>
if they had listened, there would have been a "list all extensions" kernel call right from the beginning, and we wouldn't be having this argument *now*
<davidlt[m]>
There is "phase" that you have to go through.
<djdelorie>
I try to learn from my mistakes, but I'd rather learn from others' ;-)
<davidlt[m]>
I think there was little interest into that interface until now.
<djdelorie>
sure, but who didn't see it coming?
<davidlt[m]>
Now we have multiple vendors that will depends on it :) Thus discussions are moving slightly faster.
<djdelorie>
this should have been a solved problem before the vendors started multiplying
<davidlt[m]>
This thing was discussed/mentioned for a long time :)
<davidlt[m]>
The pressure is now higher with Ventana, T-HEAD, etc.
<davidlt[m]>
Don't worry. I will make some madness too :)
<davidlt[m]>
We will need to figure out profiles things, optimized binaries or/and distributions, vendor repositories in some sane way.
<davidlt[m]>
I will repeat myself for everyone. RVA20 (today) -> RVA23 (next major future) is a significant performance gap. Don't compare that to x86_64 -> x86_64_v3 which gives 5-10% perf bump (numbers from Arch Linux some tests).
<davidlt[m]>
There are no measurable claims, but I have seen some benchmarks. The only public claim so far is T-HEAD C920. Enabling "XuanTie Instruction Extension" (which is a similar stuff to RVI ratified stuff now) gives 40% improvement in coremark. That doesn't incl. all the new stuff that's coming into RVA23.
<davidlt[m]>
I think, I have seen spec bit-manip bechmarks some long time ago, that alone was significant numbers.
<davidlt[m]>
i.e. CPU SPEC
<nirik[m]>
I've been/am in a meeting, but just skimming... does this mean there would be a desire to rebuild everything multiple times for different profiles?
<davidlt[m]>
nirik: depends. The easiest (at least for me) would be to rebuilding it per profile and avoid mixing binaries.
<nirik[m]>
thats... really sad and horrible. ;)
<davidlt[m]>
Now if you cannot rebuild everything because there is not enough HW resources for that then you need a special list of packages, and you mix them.
<davidlt[m]>
Realistically RVI wants to have a profile every 2 years. Now it happens a bit more often, but we get minor and major.
<davidlt[m]>
RVA22 is minor, kinda as a stop gap towards RVA23 (major).
<nirik[m]>
you not only need a bunch more compute cycles, you need a bunch more disk space, and you add N times more confusion to users. (which one do I use for Y? How about X?) and you have to make seperate install media for all of them and explain which to use and it's a nightmare. ;(
<davidlt[m]>
Expectation is that distributions might not support minor ones.
<davidlt[m]>
Technically installer could check HW and detect the profile.
<davidlt[m]>
Allow user to select a different one (not default, user makes a choice). Basically that would point to a different repo rva20, 22, 23.
<davidlt[m]>
If user would do nothing you get rva20 (aka today's stuff).
<davidlt[m]>
Now we also need to decide how much we trust psABI and mixing binaries built with different extensions.
<davidlt[m]>
"The critical" packages list would probably be a few hundreds max. Okay let's say <1K.
<davidlt[m]>
nirik: one more thing, RVI wants to have a way to replace/remove extensions if there is something better.
<davidlt[m]>
So far that would probably touch "supported optional" extensions.
<nirik[m]>
all this should be done at runtime, IMHO.... but I know thats a lot to try and get working.
<davidlt[m]>
nirik: that is ongoing, but it's not for everything.
<davidlt[m]>
Some packages also support dlopening uarch packages, etc.
<davidlt[m]>
Vendors will want to rebuild stuff. They always want.
<davidlt[m]>
ArchLinux has a ticket for x86-64_v3 repos.
<nirik[m]>
yes, fedora had this fight a while back. Also 'rebuild everything with frame pointers', and more.
<davidlt[m]>
nirik: I am not suggesting to change the baseline :)
<davidlt[m]>
riscv64 is "rva20" and that's not to change (in Fedora).
<davidlt[m]>
In CentOS Stream there might not be a need to have RVA20 as most (if not all) HW here will probably be RVA23.
<davidlt[m]>
But Fedora was built on pre-standard (e.g. profiles) on SBCs. It will be some years before SBCs might become compliant to some platform specification.
<nirik[m]>
sure, understood.
<davidlt[m]>
Really RVA23 is a true starting point for RISCV to enter more markets.
<davidlt[m]>
Even Android will probably end up requiring RVA23 (or higher).
<davidlt[m]>
For the users we need to stay on RVA20 because that's all we can buy these days (and tomorrow). The higher performance hardware will most likely want newer profile. Performance gap here is large.
<davidlt[m]>
If we cannot offer distribution that provides decent performance then <insert your answer here>.
davidlt has quit [Ping timeout: 268 seconds]
<nirik[m]>
Sure... but that doesn't mean we can't push back/make things better for us over others doing things without thinking about how they affect downstreams. :)