Linux 5.14 Supports Some Exciting Features With RISC-V

[uid313]

Hmmm, then I wonder what "be" means to you as RISC-V already happened. Its a instruction set and its founders want to kill ARM for all kinds of usage where ARM does not bring any benefits over being an ISA, not liberate your workstation usage. It is not a replacement for your x86 CPU.

Yes, RISC-V will not liberate anything, it will not bring any end-user freedom so then we might as well stay with ARM.

That is wrong, RISC-V chips all use something called OpenSBI. OpenSBI is basically like Coreboot and like Coreboot supporting multiple payloads like SeaBIOS, Tianocore UEFI and uboot, OpenSBI does too. This is about as standardized as it gets.

I've never heard about OpenSBI, I guess it is some RISC-V-only thing, like its not standardized by any standard body, its just a specification that happens to be open.

Someone who buys a Android Phone or a Chromebook does not care, those are not the customers for such a platform.

Most of the people in the world have an Android phone, and I believe freedom should be for everyone, not just tech giants who have freedom in their data center.

You want to run a general purpose operating system, like GNU/Linux. Then for that, you do not want a micro controller, you want a CPU with a certain set of instructions and there is a class for that, its called RVGC, what it supports beyond that does not matter.

I want more than just a CPU, I can do nothing with a CPU, I would need a system-on-a-board or a motherboard, RAM and storage.

Those things are called IP blocks, and like in the ARM world, chip makers can license those and put them on their RISC-V Silicon. Beside the popular Mali GPUs, non of those common IP blocks are made by ARM.

Yeah, theoretically chip makers can license those and put them on RISC-V silicon. Theoretically. But practically it does not exist, no chip maker seems to be interested in it.

Booting and initialization aren't part of a CPU microarchitecture. Also, neither have x86 motherboards a standard booting and initialization process: you need to port UEFI, Coreboot or whatever to your specific x86-64 SOC, motherboard chipset and other motherboard's specifics. That's why you can't just install Coreboot on any x86-64 before porting it to the board. For RISC-V it's the same, as with ARM: you have UEFI, Coreboot or U-Boot (which also implements the booting part of the EFI standard), you just need to port it to your specific board.



AFAIK, ACPI is just data on the firmware, nothing to do with the CPU architecture.

It doesn't really matter what booting and initilization is part of, or any arbitrary claim that x86 motherboard isn't standardized, because in the real world, I can boot Windows 10 and Ubuntu on any x86 computer. It doesn't matter if it is AMD or Intel, if its on a Gigabyte, Asus or MSI, when I put that x86 Linux distribution, it boots and just works.

On RISC-V you cannot put one generic image.

i don't know of any CPU architecture more plagued with extensions than x86-64... and all of them proprietary. Intel and AMD just cross-license them. On RISC-V all standard extensions are open, and in the worst case proprietary extensions will be specific of one company (instead of specific of two US companies). I don't expect popular free (libre) distributions to require proprietary RISC-V extensions, so I'm not very worried about that.

The x86-64 architecture isn't plagued by extensions. When I want to run an application or game, or any piece of software, it just works on computer regardless if it is an Intel or AMD CPU, it just works.

Most x86-64 SOC's don't have GPU, sound, network, 5G and AI accelerator (most of them are at best in the chipsets, most often on specific chips). Many of the AMD SOC'S don't have _any_ of them. Furthermore, future RISC-V SOC's for portable devices will have what you are requesting, for example Allwinner D1 has display controller, video engine, camera inputs, sound, USB, ethernet... in addition to other typical embedded interfaces like UARTs, SDIO, PWM, GPIO, ADCs etc.

x86 SoC's are boring and uninteresting, and unappealing. ARM SoC's are much more interesting. The Allwinner D1 sucks, it is like a decade old ARM board.

That's a bold statement. I'm not sure how you can say that, since a lot of chips don't advertise what cores they're using. RISC-V is already getting big in the microcontroller segment.


Do you have any idea how long it took ARM to get to the point where it could start to challenge x86? Do you think a new ISA comes out and just dominates overnight?

The only place RISC-V will be big is where is in internal subcomponents where it can replace existing ARM Cortex-M* in order to reduce license fees.

A long time, but RISC-V isn't new, its getting rather old too.

[Brane215]

End-users like you and me won't get any benefit from RISC-V such as having more competition or having an open system without binary blobs and proprietary firmware.

Don't think so. Systems are popping everywhere. Here is one - Microchip's PolarFire:

https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga

There are plenty of soft implementations also, for quite some time.
I like MIPS, but Microchip is ending that in favor of RISC-V, it seems.
Which is great.
It would be great to have line of micros, unencumbered with "special" compilers and licences.
And open door for DIY implementation, without licence hassles etc and with compiler support pretty much ready.

[uid313]

Don't think so. Systems are popping everywhere. Here is one - Microchip's PolarFire:

https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga

There are plenty of soft implementations also, for quite some time.
I like MIPS, but Microchip is ending that in favor of RISC-V, it seems.
Which is great.
It would be great to have line of micros, unencumbered with "special" compilers and licences.
And open door for DIY implementation, without licence hassles etc and with compiler support pretty much ready.

A soft implementation is useless, its like a fantasy implementation, it's not something real that can be used in the real world by people.

The PolarFire SoC is shit, it compares itself to decade old SoCs. It's not relevant to this decade, it cannot compete with contemporary SoCs. It is old technology with poor performance and legacy functionality.

[coder]

Yes, RISC-V will not liberate anything, it will not bring any end-user freedom so then we might as well stay with ARM.

If you have a bunch of RISC-V software you want to run, it lets you build a CPU to run it on. With x86, this is not an option.

For the end consumer, it means we can have any number of competing vendors, instead of just 2 x86 makers. Even for ARM, the mobile world currently has just ARM and Apple cores. Yeah Nuvia/Qualcomm and Google's Whitechapel are supposedly coming, but right now there's really just one choice of cores for non-Apple users.

I've never heard about OpenSBI, I guess it is some RISC-V-only thing, like its not standardized by any standard body, its just a specification that happens to be open.

You're missing the point. If it's a free standard that boards and operating systems can use to enable interoperability without having to patch each OS to enable each board, that's all it really needs to do!

I want more than just a CPU, I can do nothing with a CPU, I would need a system-on-a-board or a motherboard, RAM and storage.

To do big things, we need to crawl, then walk, and then run. One cannot revolutionize the computing world overnight.

Here's an interesting Libre GPU that's built around RISC-V:

https://www.eetimes.com/rv64x-a-free...pu-for-risc-v/

Yeah, theoretically chip makers can license those and put them on RISC-V silicon. Theoretically. But practically it does not exist, no chip maker seems to be interested in it.

I'm curious how you seem to be such an authority on the electronics industry.

Intel is partnering with SiFive to make RISC-V SoCs in its fabs:

https://www.anandtech.com/show/16780...on-7nm-in-2022

The x86-64 architecture isn't plagued by extensions. When I want to run an application or game, or any piece of software, it just works on computer regardless if it is an Intel or AMD CPU, it just works.

This is not correct. There are many games that require some minimum CPU spec, and part of that is due to using some instruction set extensions, like AVX2, that aren't found on older CPUs.

x86 SoC's are boring and uninteresting, and unappealing. ARM SoC's are much more interesting. The Allwinner D1 sucks, it is like a decade old ARM board.

I think you're confusing what's subjectively interesting to you with what's relevant in the industry.

A long time, but RISC-V isn't new, its getting rather old too.

It's evolving, as it was meant to do. Maybe, when it hits some fundamental limits, they will spawn RISC-VI.

[coder]

A soft implementation is useless, its like a fantasy implementation, it's not something real that can be used in the real world by people.

You use devices and infrastructure all the time with FPGAs, and those have sometimes hard cores and other times soft cores. One cool thing about soft cores is that they're field-upgradable with just a new firmware image. So, if there's some security flaw found, or a new instruction needed to accelerate the latest video codec or whatever, you don't have to physically upgrade the hardware!!

The PolarFire SoC is shit, it compares itself to decade old SoCs. It's not relevant to this decade, it cannot compete with contemporary SoCs. It is old technology with poor performance and legacy functionality.

Embedded computing is a different animal than gaming machines or general purpose computers. They operate on completely different cost scales and have different priorities.

[uid313]

If you have a bunch of RISC-V software you want to run, it lets you build a CPU to run it on. With x86, this is not an option.

With x86 and ARM I don't need no softcore, I can just develop on real hardware since real hardware is readily available.

For the end consumer, it means we can have any number of competing vendors, instead of just 2 x86 makers. Even for ARM, the mobile world currently has just ARM and Apple cores. Yeah Nuvia/Qualcomm and Google's Whitechapel are supposedly coming, but right now there's really just one choice of cores for non-Apple users.

You seem to forgot about Mediatek with their Helio, and Samsung with their Exynos, etc. HiSilicon with their Kirin. I think Xiaomi have something going too. Nvidia with their Tegra.

You're missing the point. If it's a free standard that boards and operating systems can use to enable interoperability without having to patch each OS to enable each board, that's all it really needs to do!

This seems great! It seems exactly what is needed!

Here's an interesting Libre GPU that's built around RISC-V:

https://www.eetimes.com/rv64x-a-free...pu-for-risc-v/

That's interesting. Do you think it is really viable though? For high performance?
I would love to think so, but I fear this will be like other open GPU attempts and other CPU-based GPUs that aims for 30 fps at 720p.

Intel is partnering with SiFive to make RISC-V SoCs in its fabs:

https://www.anandtech.com/show/16780...on-7nm-in-2022

Yeah, but this is not to make any end-user RISC-V boards or such, this is only for Intel to replace existing ARM or ARC microcontrollers with a RISC-V one in order to reduce license costs. It is for things like Intel Management Engine and such. Just a subcomponent for internal stuff.

This is not correct. There are many games that require some minimum CPU spec, and part of that is due to using some instruction set extensions, like AVX2, that aren't found on older CPUs.

Yeah, naturally ISAs have revisions and extensions, but this is not any indication of proprietary extensions and fragmentation. The x86 architecture is not fragmented, sure it has extensions and revisions so the ISA, but it all works good across different vendors (both Intel and AMD).

[rene]

honestly I did not expect much from unaligned copy_from/to_user, after all how often is stuff unaligned, ... so, benchmarking that it is usually not faster, sometimes even slower within al the other changes and reassuring accuracy, ... The only thing I found at times up to 4.5% faster is longer running, more memory using stuff like zstd https://www.youtube.com/watch?v=a_4EXHX_1_s

[PerformanceExpert]

honestly I did not expect much from unaligned copy_from/to_user, after all how often is stuff unaligned, ... so, benchmarking that it is usually not faster, sometimes even slower within al the other changes and reassuring accuracy, ... The only thing I found at times up to 4.5% faster is longer running, more memory using stuff like zstd https://www.youtube.com/watch?v=a_4EXHX_1_s

Not handling unaligned accesses efficiently is yet another serious mistake of RISC-V. Most small microcontrollers support it today. However RISC-V will always bear the cost of having to use inefficient variable shifts when doing a misaligned copy (even on CPUs that do add hardware support). Amazing retro 1980's thinking at its best!

Having efficient unaligned accesses improves decompression indeed since that is mostly unaligned memcpy. And it helps making most other string functions simpler and much faster.

[rene]

Not handling unaligned accesses efficiently is yet another serious mistake of RISC-V. Most small microcontrollers support it today. However RISC-V will always bear the cost of having to use inefficient variable shifts when doing a misaligned copy (even on CPUs that do add hardware support). Amazing retro 1980's thinking at its best!

Having efficient unaligned accesses improves decompression indeed since that is mostly unaligned memcpy. And it helps making most other string functions simpler and much faster.

there is nothing in the ISA spec stopping an CPU to implementing it as efficient as x86. There will be however, a huge efficiency and compatbitiliy increase from the Vector extension compared to the incompatible mess that is MMX, 3dnow, SSE*, AVX* and all the crazy new advanced matrix stuff and in general non crazy variable length instructions ;-) https://www.youtube.com/watch?v=9e9LCYt3hoc

[coder]

With x86 and ARM I don't need no softcore, I can just develop on real hardware since real hardware is readily available.

I meant some entity with the resources to build a custom CPU. For instance, let's say for use in high-radiation environments, like space. If your software is x86 then you have to go begging Intel or AMD to custom-design you a CPU, but if it's RISC-V you have more options (including making your own).

You seem to forgot about Mediatek with their Helio, and Samsung with their Exynos, etc. HiSilicon with their Kirin. I think Xiaomi have something going too. Nvidia with their Tegra.

Those are all SoC product names. MediaTek never made their own cores, Samsung stopped developing its own cores, and HiSilicon has always used cores from ARM in their mobile SoCs.

The fact is that all current, non-Apple mobile SoCs use cores designed by ARM Holdings. That's a single source for all mobile ARM cores (their main market).

That's interesting. Do you think it is really viable though? For high performance?

The question is for what applications. To start, I expect it would mainly get used for GUI acceleration on RISC-V chips. Eventually, it could mature to the point of being usable for more entertainment-oriented purposes. A lot of the GPUs in lower-end SoCs are pretty weak, so it's not hard to see it surpassing some of those.

Yeah, but this is not to make any end-user RISC-V boards or such, this is only for Intel to replace existing ARM or ARC microcontrollers with a RISC-V one in order to reduce license costs.

I sent you a link so you could read it. If you had even made it to the 3rd paragraph, you'd have seen where it said:

it would appear that Intel intends to make this a fully-featured development system, along similar lines to SiFive’s own HiFive Unmatched platform launched early this year.

Yeah, naturally ISAs have revisions and extensions, but this is not any indication of proprietary extensions and fragmentation. The x86 architecture is not fragmented, sure it has extensions and revisions so the ISA,

This is not true. There are plenty of examples where some products support certain ISA extensions and others don't. Intel's low-end cores don't support any AVX instructions, for instance, but they have some newer cache-management and security instructions.

The poster child for fragmentation in x86 has got to be AVX-512:

https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512

AMD doesn't have it, and Intel has 8 different feature combinations, so far!

it all works good across different vendors (both Intel and AMD).

The reason it works is that people put in the effort to make it work. The same is true of other ISAs with optional extensions, such as ARM, and there's no reason to think RISC-V isn't manageable in the same ways.

https://en.wikichip.org/wiki/arm/arm...essor_Features