AMD Readies "New Stuff" For Linux 6.6 Graphics Driver, AMDGPU DC For RISC-V

[Lycanthropist]

"Gamers" don't need high end systems anymore, and like before haven't for a long time, some gamers do yes, but I don't think it's a safe assumption that even ignoring gaming, that the statement is wrong to a large degree.

It always depends on the usecase. Just because the performance is enough for your usecase doesn't mean it's enough for everyones use case.

[Quackdoc]

It always depends on the usecase. Just because the performance is enough for your usecase doesn't mean it's enough for everyones use case.

yes, that would be what I said.

[uid313]

Price, can't say. But you won't have to wait 10 years for Performance and Power, as the RISC-V microarchitecture "Ascalon" is due 2024:

Note how the performance of the RISC-V Ascalon microarchitecture is comparable to the projected performance of Zen5. They will both release in 2024.

RISC-V is inevitable.

What makes you think that you will be able to buy a Ascalon for your computer at home?
I think Ascalon will only be for sale to big tech companies for their data centers.

[stiiixy]

I seriously hope Jim Keller gets the backing for this project. He did after all, do some heavy lifting for AMD to get Zen going.

[Gusar]

RISC-V is inevitable.

Wake me up when there's some sort of agreed upon "desktop RISC-V extension set" and CPUs sporting that set that you can socket into ATX form boards (for case and add-in card compatibility) and a universal way to boot the system and enumerate all peripherals (as bloated and overkill as UEFI might be, it lives up to the U in its name).

Until then RISC-V will be a fragmented mess, where you need not only a board-specific kernel, but often board-specific OS images, due to the lack of a universal boot and each CPU having their own set of often proprietary extensions.

Yeah, I'm gonna rustle some feathers with this post, but right now RISC-V is even more fragmented and proprietary than even ARM, and that's saying a lot.

[Quackdoc]

Wake me up when there's some sort of agreed upon "desktop RISC-V extension set" and CPUs sporting that set that you can socket into ATX form boards (for case and add-in card compatibility) and a universal way to boot the system and enumerate all peripherals (as bloated and overkill as UEFI might be, it lives up to the U in its name).

Until then RISC-V will be a fragmented mess, where you need not only a board-specific kernel, but often board-specific OS images, due to the lack of a universal boot and each CPU having their own set of often proprietary extensions.

Yeah, I'm gonna rustle some feathers with this post, but right now RISC-V is even more fragmented and proprietary than even ARM, and that's saying a lot.

RV64GC seems to be pretty ubiquitous. ofc this may be expanded in the future, but what doesn't?

[ayumu]

Wake me up when there's some sort of agreed upon "desktop RISC-V extension set"

Already there.

We have an already ratified RISC-V Profiles spec. The one that's relevant to your use case is RVA22.

But it goes further (work in progress) by also defining the platform. Like there are informally the IBM PC clones, there's formally the OS-A Platform. See platform spec.

Relevant mass market SoCs already out there (JH7110 and TH1520) implement the end of 2019 analog to RVA22, RV64GC+Zcsr, now retroactively named RVA20.

Note that RVA22 has the important batch of extensions approved by the end of 2021, which include hypervisor extension, vector extension and a bunch of bit manipulation extensions. These enable high performance datacenter, workstation, laptop as well as smartphone applications, and will show up in 2024.

AIUI, Ascalon implements RVA22.

[smitty3268]

Note how the performance of the RISC-V Ascalon microarchitecture is comparable to the projected performance of Zen5. They will both release in 2024.

Comparable performance isn't good enough. They need something far superior than x86_64 if they expect mass conversion, because otherwise most people will prefer to keep using what they already have. For very valid reasons - a lot of software will work better on the systems it was designed/optimized for, if it will run on risc-v at all.

See ARM, for example, which is still pretty niche outside mobile today even after Apple and Amazon have shown it can be better than the competition. And ARM64 is comparably much better supported than RISC-V, with all the work that's gone into mobile platforms over the last decade.

[Quackdoc]

Comparable performance isn't good enough. They need something far superior than x86_64 if they expect mass conversion, because otherwise most people will prefer to keep using what they already have. For very valid reasons - a lot of software will work better on the systems it was designed/optimized for, if it will run on risc-v at all.

See ARM, for example, which is still pretty niche outside mobile today even after Apple and Amazon have shown it can be better than the competition. And ARM64 is comparably much better supported than RISC-V, with all the work that's gone into mobile platforms over the last decade.

I disagree with this, as long as it meets the minimum performance threshold and an acceptable cost it could see adoption assuming the devices can actually be maintained, this is something arm never did.

[smitty3268]

I disagree with this, as long as it meets the minimum performance threshold and an acceptable cost it could see adoption assuming the devices can actually be maintained, this is something arm never did.

Why do you think ARM failed at this, and what makes RISC-V different?