RISC-V Vector ISA Support Slated For Linux 6.5

[phoronix]

Phoronix: RISC-V Vector ISA Support Slated For Linux 6.5

Support for RISC-V's Vector ISA is now expected to be merged for the upcoming Linux 6.5 kernel merge window...

https://www.phoronix.com/news/RISC-V-Vector-ISA-For-Linux-6.5

[willmore]

I don't know enough about the instruction encoding for these, but does this impact all the chips using 0.71 of the draft version?

[tuxd3v]

I don't know enough about the instruction encoding for these, but does this impact all the chips using 0.71 of the draft version?

I don't know enough, but probably it will because there are incompatibilities..
The versions that should officially be supported are the ratified versions, in this case its the 1.0

We know that some decided to go ahead and implement versions that were not ratified, those now will have to redo their designs.
You should always implement ratified extensions, otherwise you will have to built all the software for your own version..

This problem is not only for V extension, but also for proprietary extensions..I think riscv people should sit down and have very very mature conversations, and start to standardize all the stuff they have being implementing, because otherwise big problems could happen..

We just need to look to binutils, its unmanageable, to support zillions of proprietary extensions.riscv companies need to explain why they need extra instructions, and if those are really needed, they should be added to the standard as a best practice.

One of the things that I am waiting to see ratified, its the nested vectored hardware accelerated Interrupt controller, which is a necessity for microcontrollers.They ratified I think some time ago the E, version for microcontrollers with half of the registers, 16, there are proposals for the hardware accelerated nvic but no ratification yet..

Anyway, I am happy to see support for the V extension

[ayumu]

I don't know enough about the instruction encoding for these, but does this impact all the chips using 0.71 of the draft version?

0.7.1 and 1.0.0 are indeed incompatible. Only the latter is officially ratified.

[bezirg]

Let's hope RISC-V hardware with RVV 1.0 vectors comes soon enough. I have a bunch of RVV 0.71 hardware but I doubt that they will get support.

[brent]

Finally! RVV is significant missing puzzle piece to make RISC-V feasible for many use cases! It took far too long to get this stabilized though.

[andrei_me]

Speaking of this vector stuff, I remembered of that GPU that was going to be based on RISCV and later on changes to OpenPower or something, what happened to that vaporware Michael ?

[EphemeralEft]

Am I the only one that hates all of these extensions? Isn’t the literal point of a Reduced Instruction Set Computer to have as few instructions as possible? ARM started out as a RISC but they kept adding stuff until they became a CISC. It seems like “RISC”V is doing the exact same thing.

[Jabberwocky]

Am I the only one that hates all of these extensions? Isn’t the literal point of a Reduced Instruction Set Computer to have as few instructions as possible? ARM started out as a RISC but they kept adding stuff until they became a CISC. It seems like “RISC”V is doing the exact same thing.

(I'm writing this with a laptop/desktop user's perspective who doesn't really follow RISC-V development)

How will the ISA compete if it doesn't provide industry standard features? How is this different from what ARM is doing?

My perspective: Around the time when the terms RISC and CISC were defined the distinction mattered a lot. Computers didn't have a lot of memory. The pros and cons mattered. IMO These days the RISC vs CISC argument isn't as important. The industry is demanding a lot from general purpose CPUs and it's not as simple as things were back in the day. These days you want crypto, avx, AI, igpu with media asic... etc.

Do you think RISC-V shouldn't provide features to remain competitive and just target a small part of the market?

PS: With regards to what tuxd3v said about proprietary standards: That seems like a silly spaghetti mess waiting to happen. I completely agree with "to support zillions of proprietary extensions.riscv companies need to explain why they need extra instructions, and if those are really needed, they should be added to the standard as a best practice."