No. I'm not touching a generic Linux desktop ever again. Which is so far every RISC-V Linux youtube video shows it being.
I am waiting for Windows on RISC-V or Solus 5.x on RISC-V ("Be ported to other architectures than x86_64, such as AArch64 and RISC-V, in the future"). Daily driving with RISC-V requires the former or the latter.
Can you show some expected CPU that will be good for desktop/laptops and that doesn't have performance of 5 years old Arm cores (that is completely inadequate)?
And that doesn't change the fact that currently RISC-V CPU are only used as low cost embedded CPU in end user applications (such SSD controller). This means they didn't reach the market Arm already had at the end of last century/early this century when it was used as the main core of most of mobile phones.
They still have a long way in front of them and the 10 years some predicted likely is the lower bound.
Veyron V2 (mid-2024) probably won't appear till Hotchips 2024. Which has its submissions submitted around ~March 2024, final version around ~July 2024, etc.
+40% performance from Veyron V1 which never got a product.
Ascalon (target: 2024) has been in this forum for sometime:
CCO's position(get as much silicon to the masses)/experience(past work) leans more towards Personal Computing projects.
No prior announcements, thus can come out anytime:
Rivos got to (dropped/settled) with Apple. So, they are likely to get out of stealth soon with an Apple-esque core.
Akeana is also still in stealth, but like Rivos is for Apple/Qualcomm... Akeana is for Cavium/Sun/Oracle/etc. I am adjusting this to be more against POWER instead.
AMD in general has experience converting their cores from x86-64 to RISC. So, it won't be surprising if they take a VIA "Isaiah" approach and launch after.
All of the above, are supersets of the ISA in the P670. So, any OSes that grab the SG2380 will automatically get support of the above CPUs.
Last edited:
Zen 5 performance from RISC-V???
Holy &*&$#$#%%^^^$$@#@#@#@#@$$#%$%$!!!!!!
That would be the beginning of end of x86
But would that be -5% or +40% over Zen4 ?
As soon as something starts, it's the beginning of its end. It can just take forever to happen.That would be the beginning of end of x86
SarahKerrigan
Senior member
- Oct 12, 2014
- 735
- 2,035
- 136
Meanwhile, in the real world: some licensable RISC-V cores exist that offer performance only moderately behind current ARM IP, but no merchant silicon; Ventana's numbers have been pretty unimpressive and while they've produced a lot of paper, silicon has been in short supply; Rivos and Akeana are stealth-mode and have released no details of their uarch; and Tenstorrent makes AI accelerators with a sideline in licensable IP.
None of these are coming to laptops any time soon, and RISC-V remains a deeply mediocre ISA with fragmentation problems that are already becoming readily apparent.
Would behoove some folk here to calm themselves, especially when replying to posters with a long history of, shall we say, creative claims.
None of these are coming to laptops any time soon, and RISC-V remains a deeply mediocre ISA with fragmentation problems that are already becoming readily apparent.
Would behoove some folk here to calm themselves, especially when replying to posters with a long history of, shall we say, creative claims.
Supposing Ascalon does launch in 2024 with the claimed performance level, wouldn't it become the dominant RISC-V ISA all in one fell swoop?
SarahKerrigan
Senior member
- Oct 12, 2014
- 735
- 2,035
- 136
Launch as what? IP? The control-plane core for an AI accelerator? And no! The large majority of RV cores shipped have vastly lower performance targets, and many of them have very different (often proprietary) extension sets - or, worse, incompatible draft instruction sets because of the RV Foundation's tendency to leave things in draft status, arguing over minutiae, for many years!
Please exercise critical thinking on this stuff! Hype is not necessarily your friend!
FlameTail
Diamond Member
- Dec 15, 2021
- 4,384
- 2,757
- 106
There's one thing in RISC-V I hate even more that its poor ISA, it's the marketing/hype that surrounds it. The supposed "freedom" of R-V has turned into anarchy (and this is history repeating, it happened to MIPS too).
It also seems people don't realize most advanced micro-architectures are protected by a lot of patents. So small companies that don't have an existing portfolio of patents to prevent attacks may face very difficult times (that's not the case of AMD).
Also development costs of chips are huge. And I'm not sure paying royalties for high-end chips would change anything in the final cost (what are a few dollars for chips costing hundreds of dollars?).
It also seems people don't realize most advanced micro-architectures are protected by a lot of patents. So small companies that don't have an existing portfolio of patents to prevent attacks may face very difficult times (that's not the case of AMD).
Also development costs of chips are huge. And I'm not sure paying royalties for high-end chips would change anything in the final cost (what are a few dollars for chips costing hundreds of dollars?).
SarahKerrigan
Senior member
- Oct 12, 2014
- 735
- 2,035
- 136
I'm not sure that RISC-V is where you're likely to find good stuff.
Not for the consumer for sure.
Clearly for SoC vendors that isn't the case though, given the whole dispute between ARM and Qualcomm.
No, the ISA is controlled by the Profiles/TSC Group. Not the people making the CPUs. No one is stopping those with the hardware design IP/know-how to making a competitor. There is no ARMv9/SVE downgrade or APX/AVX10 gacha moments for RISC-V.
Android and Tizen (https://wiki.riseproject.dev/display/HOME/Tizen+RISC-V+Status):
"The latest update that we have is that now not only are we accepting patches, but we have begun to mature support for RISC-V in Android. RISC-V is a modular ISA, meaning that there are a large number of optional extensions. We have also determined an initial set that we feel is critical to ensure that any CPU running RISC-V will have all of the features we expect to achieve high performance. This set includes the rva22 profile as well as the vector and vector crypto extensions."
RVA22 is ratified, Vector is ratified, Vector Crypto is ratified, thus RVA23(non-major release, ratification is not required) can be used for those that have all extentsions.
No one is going to make custom instructions if there is standard instructions available.
Samsung is the only one I would list as going Mobile first. Example being: Tenstorrent Ascalon license (part of the agreement to fab at Samsung) + Co-dev Voyager/Xclipse RDNA-clone IP (can use with other tech is part of agreement with AMD).
SarahKerrigan
Senior member
- Oct 12, 2014
- 735
- 2,035
- 136
As with before, I would happily bet a large sum of money that Samsung is not going to launch a phone with a top-end Tenstorrent core in it in the next several years.
As for custom instructions, Qualcomm already said they need 'em. Andes has already been shipping custom ops. And vectors aren't the only problem with RV ISA facilities.
The additional "custom" instructions won't be used in any general release RISC-V image. Qualcomm/Rivos doesn't need the custom ops, it is unlikely they will be used in general market. Andes custom ops are to make it more compatible with older AndeStar RISC ISAs; RISC-V (RVA22) + AndeStar Compatibility. If the software platform isn't already AndeStar, then no one will use those custom instructions. AndeStar V1 -> AndeStar V3 -> AndeStar V5, if the customer is just coming for RISC-V. Then, the AndeStar instructions won't be used.
So spooky: https://developer.arm.com/Architectures/Arm Custom Instructions
It is only a matter of time before ARMv8-A/v9-A goes Custom as well!
"With Arm Custom Instructions, you have more flexibility to innovate within the Arm worldwide standard at your own pace."
Last edited:
SarahKerrigan
Senior member
- Oct 12, 2014
- 735
- 2,035
- 136
No. Andes has made clear that Andestar V5 is not for "compatibility" with existing Andes RISC. You realize they've proposed it for integration into the RISC-V spec as the "P" extension, right? No? Of course not.
I know your whole shtick is making up all manner of implausible crap, but come on. It's losing its charm.
The only profile getting the P-ext is the RVM profile. RVA/RVB are Vector-only on TSC discussions.
The P-extension is from AndeStar V3. "Andes would like to contribute our >150 DSP and Packed SIMD instructions (or simply DSP ISA) developed in our AndeStar V3 architecture as a starting basis for the RISC-V “P” extension."
Every single custom "Andes" performance/density/etc instruction is from an AndeStar product. Meant to keep the product compatible with older architectures from Andes.
What is Voyager?
Also it's not an RDNA clone, it IS RDNA - they just designed it for TSMC nodes so it performed less than ideally on Samsung's, and they will have to start from scratch again with the 3nm GAA node.
I was under the impression that this was ARM basically just legitimising Apple's matrix ops thing?
SarahKerrigan
Senior member
- Oct 12, 2014
- 735
- 2,035
- 136
So, caught in a direct lie:
You immediately send the goalposts flying to "welllll, they're derived from Andes RISC and won't go into the RVA profile."
Clown.
Voyager/Angle is the licensed IP name once it goes in the product (Xclipse is the market name). Samsung re-stated agreement with AMD allows them to do more than just re-spin AMD's design. So, it is more like Hygon's Dhyana now.
Next GPUs found/leaked/etc:
Magellan
Titan
Ariel
You are the one moving the goal post of a custom instruction. Basically, come Q2'24 they can drop the P-ext.
The current maintainer for P extension is NOT Andes, by the way. It is basically starting from scratch again with Berkley UC handling it. As the vector crypto extensions utilizes the P-ext opspace. https://github.com/riscv/riscv-opcodes/issues/146#issuecomment-1362708942
"Vendors claiming support for "P" are claiming support for something that isn't a RISC-V standard. So it isn't really relevant."
In this case, with the P ext: Fractional LMUL/SEW in V-ext can be used to do P-ext.
128-bit Unit/VLEN=128 => mf2/111 # LMUL=1/2 and 000 # SEW=8 is equivalent to an 8-bit*8 Packed op.
Custom instructions will not be used by software in the general market. Any custom instructions will not be used anywhere (generic-image). Stop moving the goal post that never existed. RVA is the only standard being supported for Datacenters/Desktops/Laptops. Unless for example, Qualcomm/Rivos accept the maintainership of RVH "High Performance" profile. However, it is unlikely they will actually do that.
Andes purpose of P-ext is to make RISC-V DSP compatible with AndeStar V3. Every AndeStar RISCV custom instruction is to make it compatible with AndesStar V1/V3. No one is going to use Andes custom instructions in their products. As it IS not mandated to use them, only RVM23 has P-ext.
Andes RISC-V Performance custom ISA = AndeStar V3 Performance [V1+V2] ISA // Which is replaced by Bitmanips
Andes RISC-V CoDense custom ISA = AndeStar V3 Density (Mixed-length) ISA // Which is replaced by Compressed
etc.
The extensions used by software in the general market (Android/Tizen/Windows/ChromeOS/FuschiaOS/Linux) will be the standard ones. Which will not be Qualcomm custom, Andes custom, somecompany custom instruction set.
"For some deep embedded markets, highly customized processor configurations are desirable for efficiency, and all software is compiled, ported, and/or developed in-house by the same organization for that specific processor configuration. However, for other markets that expect a substantial fraction of software to be delivered to end-customers in binary form, compatibility across multiple implementations from different RISC-V vendors is required.
...
The primary goal of the RVA profiles is to align processor vendors targeting binary software markets, so software can rely on the existence of a certain set of ISA features in a particular generation of RISC-V implementations." - RVA Profile overview
For example: No one in the general market has used RISC-V Turbo/"XIE (XuanTie Instruction Extension)" for T-head's C910. Even though it actually has purchasable products: TH1520 and SG2042. These products are only running RV64GC/RVA20, not even the RVV 0.7.1 custom instruction set is being used.
On progress with RISC-V: there is only one instruction preventing Server RISC-V and it is a instruction tied to AutoFDO:
"RISC-V ISA extension (proposal) to allow recording of control transfer history to on-chip registers, to support usages associated with profiling and debug."
After which, this is done: https://wiki.riseproject.dev/display/HOME/SE_01_022+-+RISC-V+Server+SoC+Referece+Board
RISC-V will be everywhere.
"RISE Optimization Manual" :: target hardware: smartphone, laptop, desktop, server; OoO; rv64gv*
Ventana/Tenstorrent are server first. AMD is on RISE, with AMD Strategic Silicon Solutions being involved.
Bare minimum is Oasis going forward. Everything will speed up with hardware (esp. closer to Spec Target) becoming available.
Ventana's/Imagination's Veyron V2+Imgtec DXD APU is likely to be available after October 22-23, 2024
Vulkan 1.3, OpenGL 4.6 via Zink, OpenGL ES 3.2, Open CL 3.0, DirectX 11_0 FL, (DirectX 12_2 over time with VKD3D).
Last edited:
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 24K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 20K
-
-
-
Facebook
Twitter