Imagination Announces "Catapult" RISC-V CPU Family

[coder]

That seems to be good news, if its real what they are talking about more commitment to the Linux kernel..
Hope that this time, they bring support for their SoCs and Graphics..
They need to start by some place, hiring Linux developers is a good start..

Most of the customers for their new RISC-V SoCs will want to run Linux on it. So, they'll naturally have to beef up Linux support.

And don't enough Android tablet/phone/Chromebook type devices already use their GPUs that they should actually work, under Linux?

[tuxd3v]

Most of the customers for their new RISC-V SoCs will want to run Linux on it. So, they'll naturally have to beef up Linux support.

And don't enough Android tablet/phone/Chromebook type devices already use their GPUs that they should actually work, under Linux?

I hope they will have proper support..
For android and such, they should, but I don't really know about GNU/Linux..

They are also trying to come to bigger performance desktop and server markets, lets see..

https://www.techpowerup.com/289123/innosilicons-fenghua-gpu-based-on-imagination-technologies-img-b-series-gpu-cores

It would be nice to have other options apart from AMD, Nvidia and in the future Intel too..
innosilicon says its graphics cards will have a very strong GPFPU compute, around 70% faster than what is in the market.. lets see..

[coder]

They are also trying to come to bigger performance desktop and server markets, lets see..

https://www.techpowerup.com/289123/innosilicons-fenghua-gpu-based-on-imagination-technologies-img-b-series-gpu-cores

It would be nice to have other options apart from AMD, Nvidia and in the future Intel too..
innosilicon says its graphics cards will have a very strong GPFPU compute, around 70% faster than what is in the market.. lets see..

Cool! Yeah, I always wondered how well Imagination's GPUs would scale up.

[microcode]

Until recently, a lot of RISC-V extensions were only drafted and not on paper

...what?

[microcode]

Not sure why so many people are complaining, this looks great!

Even if it were “great”, it doesn't matter if the software is too frustrating to turn into a useful or fun product. I'm sure everyone here, with the exception of competing vendors, would love to see more quality competition in this space; but people who have had any contact with Imagination's previous products are skeptical that they can deliver something good. When Apple used Imagination's GPUs, I ran into all sorts of horrible system-crashing graphics driver bugs when working on iOS applications; I've had similar experiences with Imagination drivers on other platforms, it's hot garbage every time.

[tuxd3v]

...what?

On December 2 2021, were ratified 15 new specifications..

https://riscv.org/announcements/2021/12/riscv-ratifies-15-new-specifications/

The extensions [V]ector, [K]Scalar Cryptography, and [H]ypervisor were ratified..
For me [K]Scalar Cryptographic, and [V]ector ones are the most important.. even thought that a lot of companies are already using dedicated cryptographic engines, Scalar Crypto, can according to RISCV accelerate till 2x code in some areas..

For me, the most important one will be the [V]ector extension, 186 instructions..
hope gcc toolchain, binutils, etc get actualized fast, also that debian use after that RV64GCV, instead of only RV64GC..

[microcode]

On December 2 2021, were ratified 15 new specifications..
https://riscv.org/announcements/2021...pecifications/

The extensions [V]ector, [K]Scalar Cryptography, and [H]ypervisor were ratified..
For me [K]Scalar Cryptographic, and [V]ector ones are the most important.. even thought that a lot of companies are already using dedicated cryptographic engines, Scalar Crypto, can according to RISCV accelerate till 2x code in some areas..

For me, the most important one will be the [V]ector extension, 186 instructions..
hope gcc toolchain, binutils, etc get actualized fast, also that debian use after that RV64GCV, instead of only RV64GC..

SiFive has a brilliant compiler team lead on V, both LLVM and GCC will have good upstream vector support by the time any products are widely available.

As for targeting the vector extension as a base ABI component, that's not necessary; there's infrastructure to resolve that at runtime, in fact there are a couple good solutions.