> Nowadays, programs requiring floating point hardware acceleration for reasonable performance use vector machine instructions.
While some very-important software like video codecs, and various sporadic projects where some drive-by open-source dev decided to add an optimized path will use vector, that's, like, on the order of 0.001% (number out of my ass) of all software that runs slowly enough to be noticable, and the remaining 99.999% remains slow. Much as I like working with SIMD/vector, it's a very tiny minority of people that do.
RVV does also actually make good use of scalar FP, with .vf instruction variants which take one operand from the scalar registers, allowing storing constants in the scalar registers instead of wasting vector registers (and with LMUL it's very easy to exhaust the entire RVV register file). Especially important in matmul kernels.
> What I am very sure of: nobody wants to design a clean and modern ISA to handle the "bad" programs
And yet that's what RVA23 & co basically have to be, and are. And as such they have scalar FP, vector FP, and basically everything else that's potentially useful (other than 3-source-operand instructions).
I do wonder how much compressed actually benefits perf-wise, but it's very clearly true that, at least icache-wise, reducing code size by, say, 20%, is equivalent to adding 20% more icache; and 20% of a typical L1 icache is quite a lot of area to save.
dav1d is AV1 decoding with C code just for posture: nearly everything is assembly using vector machine instructions from arm64 to x86_64 avxNNN, and of course risc-v.
I don't even mention ffmpeg.
RVAXX looks like more a grab bag to match x86_64 and aarch64, feature wise, and it includes bad features: this is very probably to ease porting only.
In a risc-v world, there would be much more assembly of code path variants (cross-vendor neutral-ish), and high level languages with assembly written interpreters.
No more C42+ , only ultra-stable-in-time core-ish ISA assembly... and Big Tech hates that because planned obsolescence is excrutiatingly harder to do.
dav1d is still in the "some very-important software" group; the vast vast majority of software doesn't and will not write everything in assembly. If you think RISC-V is gonna in any way change that, you're.. just trivially simply plain wrong, 99.999% of people will not bother learning assembly regardless of how good of an idea you think that'd be. (never mind that even if more people learned assembly, 99.999999% of said assembly would be full of system-killing bugs)
RVA23 doesn't in any way ease porting, no clue what you're on about there; besides vectorizable code, where you necessarily do simply just need RVV or similar to get good performance, base RV64G does just cover everything needed for software to be able to run. All RVA23 does is just provide a baseline with extensions to be able to achieve good performance, and cheap instructions that software should've been already utilizing for decades but hasn't generally been able to due to legacy hardware not supporting them (importantly clz/ctz/cpop, but also to a smaller extent min/max, zicond, bit rotates).
Granted, RVA23 does have some more questionable (though still actually useful) inclusions like the cache block ones that force 64-byte cache lines to not be dysfunctional, but that also brings up the massive wart of mandatory 4K pages in base RISC-V, not even RVA23, that's explicitly chosen for ease-of-portability.
Maybe RV64 is the end-of-line for CPUs, but, for all we know, RV64 today might be what Intel 8086 was in 1978, and RV64 is to be extended and grown and eventually just replaced in the future.
While some very-important software like video codecs, and various sporadic projects where some drive-by open-source dev decided to add an optimized path will use vector, that's, like, on the order of 0.001% (number out of my ass) of all software that runs slowly enough to be noticable, and the remaining 99.999% remains slow. Much as I like working with SIMD/vector, it's a very tiny minority of people that do.
RVV does also actually make good use of scalar FP, with .vf instruction variants which take one operand from the scalar registers, allowing storing constants in the scalar registers instead of wasting vector registers (and with LMUL it's very easy to exhaust the entire RVV register file). Especially important in matmul kernels.
> What I am very sure of: nobody wants to design a clean and modern ISA to handle the "bad" programs
And yet that's what RVA23 & co basically have to be, and are. And as such they have scalar FP, vector FP, and basically everything else that's potentially useful (other than 3-source-operand instructions).
I do wonder how much compressed actually benefits perf-wise, but it's very clearly true that, at least icache-wise, reducing code size by, say, 20%, is equivalent to adding 20% more icache; and 20% of a typical L1 icache is quite a lot of area to save.