5 ms·

Could be the best thing that's ever happened for RISC-V!

dietr1ch 2y ago
I think it's already a great thing for RISC-V, imagine things somehow go well for Qualcomm, do you really think they wouldn't prepare a plan B given ARM tried to get them out of the market?
- nahnahno 2y ago
  I don’t think they have a plan B. Architectures take half a decade of work. Porting from risc-v to arm is not a matter of a backup plan, it’s that of a very costly pivot.
  - gjsman-1000 2y ago
    No kidding; and while RISC-V is a massive improvement, I hate to be the wet blanket, but RISC-V will not change signed boot, bootloader restrictions, messy or closed source drivers, carrier requirements, DRM implementation, or other painful day to day paper cuts. Open source architecture != Open source software and certainly != Open source hardware; no matter what the YouTubers think.
    - deleted 2y ago
      [deleted]
    - Atotalnoob 2y ago
      Until arm or risc-v fix standardize the bootloader, it’s always going to be a big deal for each arm/risc device added anywhere…
      - snvzz 2y ago
        Relevant RISC-V specs were released years ago and implementations follow them. I know of no boards that have application processors and yet not implement SBI. Furthermore, everybody seems to be using the opensbi implementation. ARM and RISC-V are not the same.
  - betaby 2y ago
    I suppose Google ( + Samsung ) can bear that cost in the context of Android Arm -> Android RISC-V.
  - snvzz 2y ago
    Qualcomm's been involved with RISC-V for several years now. If anything, ARM is the plan B that they'll likely end up abandoning.
    - dagmx 2y ago
      It’s a bit much to say their primary product that they’ve done for decades is a plan B. By definition it cannot be a plan B if it’s executed first and is successful. I think a lot of RISC-V advocates are perhaps a little too over eager in their perception of the landscape.
      - snvzz 2y ago
        Typo. Meant to write "ARM is the plan A that they'll likely end up abandoning".
  - mkl 2y ago
    Qualcomm has been working on RISC-V for a while, at outwardly-small scale. It's probably intended as a long-term alternative rather than a ready-to-go plan B. From a year ago: "The most exciting part for us at Qualcomm Technologies is the ability to start with an open instruction set. We have the internal capabilities to create our own cores — we have a best-in-class custom central processing unit (CPU) team, and with RISC-V, we can develop, customize and scale easily." -- https://www.qualcomm.com/news/onq/2023/09/what-is-risc-v-and-why-were-unlocking-its-potential https://www.qualcomm.com/news/onq/2023/09/what-is-risc-v-and..., more: https://duckduckgo.com/?q=qualcomm+risc-v&t=fpas&ia=web https://duckduckgo.com/?q=qualcomm+risc-v&t=fpas&ia=web
    - hajile 2y ago
      Qualcomm pitched a Znew extension for RISC-V that basically removes compressed (16-bit) instructions and adds more ARM64-like stuff. It felt very much like trying to make an easier plan B for if/when they need/want to transition from ARM to RISC-V. https://lists.riscv.org/g/tech-profiles/attachment/332/0/code_size_extension_rvi_20231006.pdf https://lists.riscv.org/g/tech-profiles/attachment/332/0/cod...
  - brucehoult 2y ago
    Qualcomm have a Plan B. This time last year they were all over the RISC-V mailing lists, trying to convince everyone to drop the "C" extension from RVA23 because (basically confirmed by their employees) it was not easy to retrofit mildly variable length RISC-V instructions (2 bytes and 4 bytes) to the Aarch64 core they acquired from Nuvia. At the same time, Qualcomm proposed a new RISC-V extension that was pretty much ARMv8-lite. The proposed extension was actually not bad, and could very reasonably be adopted. Dropping "C" overnight and thus making all existing Linux software incompatible is completely out of the question. RISC-V will eventually need a deprecation policy and procedure -- and the "C" extension could potentially be replaced by something else -- but you wouldn't find anyone who thinks the deprecated-but-supported period should be less than 10 years. So they'd have to support both "C" and its replacement anyway. Qualcomm tried to make a case that decoding two instruction widths is too hard to do in a very wide (e.g. 8) instruction decoder. Everyone else working on designs in that space ... SiFive, Rivos, Ventana, Tenstorrent ... said "nah, it didn't cause us any problems". Qualcomm jumped on a "we're listening, tell us more" from Rivos as being support for dropping "C" .. and were very firmly corrected on that.
    - wmf 2y ago
      Dropping "C" overnight and thus making all existing Linux software incompatible is completely out of the question. Android was never really Linux though.
      - refulgentis 2y ago
        This is officially too much quibbling, even if we settled philosophical questions like "Is Android Linux?" Then "If not, would dropping C make RISC nonviable", there isn't actually an Android version that'll do RISC anywhere near on the horizon. Support _reversed_ for it, got pulled 5 months ago
        snvzz 2y ago
        >Support _reversed_ for it, got pulled 5 months ago Cursory research will yield that this was a technicality with no weight in Google's strong commitment to RISC-V Android support.
  - snvzz 2y ago
    It would be naive to think that Qualcomm is only starting its RISC-V effort today and from scratch.
bhouston 2y ago
Most people do not realize how slow RISC-V is right now. Yes, it will definitely get better, but it will take some time given how far behind it is. Like 30x slower than a top of the line Apple Mx series CPU. Maybe there is a high performing RISC-V chip out there but I haven't yet run into one. RISC-V benchmarks: https://browser.geekbench.com/search?q=RISC-V https://browser.geekbench.com/search?q=RISC-V. Compare to an Apple M4 benchmark: https://browser.geekbench.com/v6/cpu/8224953 https://browser.geekbench.com/v6/cpu/8224953 That said, RISC-V is good for embedded applications where raw performance isn't a factor. I think no other markets are yet accessible to RISC-V chips until their performance massively improves.
- tightbookkeeper 2y ago
  Is it slower by design or just because it’s implementations have not been aggressively optimized?
  - bhouston 2y ago
    I believe it is just lacking aggressive optimization. ARM is basically RISC as well, so it isn't an architectural limitation.
    - tightbookkeeper 2y ago
      (Naive question) then is it really a big hurdle for a company who knows how to make arm chips to try making riscv chips?
      - bhouston 2y ago
        I suspect not? I think the principles and methods of optimization are the same. But I say this as a software guy who doesn't actually know CPU design.
      - 1123581321 2y ago
        It’s not a big hurdle so long as they hire Jim Keller to rapidly improve yet another architecture. (Only half-joking.)
dagmx 2y ago
Maybe fine for Android but this will set their windows plans back another decade if it happens It has taken them that long to make arm be a thing on windows and that’s building on people porting stuff to arm for Mac to finally get momentum. RISC-V with windows will be an eternity to be feasible.
- snvzz 2y ago
  >RISC-V with windows will be an eternity to be feasible. Will it now? Microsoft was already deeply involved in 2021 as per that years' summit RISC-V Foundation's technical talks. Ztso was pushed by them.
  - dagmx 2y ago
    Whether Microsoft has windows running on an architecture is a very different level from whether it’s feasible to use it as a daily driver on windows. The ecosystem is what matters for most people. Windows for arm hails back to 2011. They’re only just now getting native arm ports for several major packages. That’s ~13 years for a well established architecture that’s used much more universally than RISC-V. They don’t even have arm ports for lots of software that has arm ports on macOS. RISC-V will take an aeon longer to get a respectable amount of the windows ecosystem ported over.
    - snvzz 2y ago
      >The ecosystem is what matters for most people. Absolutely agree. The key development Microsoft has demonstrated recently is the ability to run x86 Windows software in non-x86 Windows systems. Now that this is in place -and will only get better-, there is no longer a chicken and egg situation. Instead, what we have is a clearly defined path to migrate away from x86.
    - Atotalnoob 2y ago
      Arm on windows may date to 2011, but it was mostly a side project with 1-2 maintainers. With sufficient investment, it shouldn’t take 13 years to build up RISC-V support.

I think it's already a great thing for RISC-V, imagine things somehow go well for Qualcomm, do you really think they wouldn't prepare a plan B given ARM tried to get them out of the market?

nahnahno 2y ago
I don’t think they have a plan B. Architectures take half a decade of work. Porting from risc-v to arm is not a matter of a backup plan, it’s that of a very costly pivot.
- gjsman-1000 2y ago
  No kidding; and while RISC-V is a massive improvement, I hate to be the wet blanket, but RISC-V will not change signed boot, bootloader restrictions, messy or closed source drivers, carrier requirements, DRM implementation, or other painful day to day paper cuts. Open source architecture != Open source software and certainly != Open source hardware; no matter what the YouTubers think.
  - deleted 2y ago
    [deleted]
  - Atotalnoob 2y ago
    Until arm or risc-v fix standardize the bootloader, it’s always going to be a big deal for each arm/risc device added anywhere…
    - snvzz 2y ago
      Relevant RISC-V specs were released years ago and implementations follow them. I know of no boards that have application processors and yet not implement SBI. Furthermore, everybody seems to be using the opensbi implementation. ARM and RISC-V are not the same.
- betaby 2y ago
  I suppose Google ( + Samsung ) can bear that cost in the context of Android Arm -> Android RISC-V.
- snvzz 2y ago
  Qualcomm's been involved with RISC-V for several years now. If anything, ARM is the plan B that they'll likely end up abandoning.
  - dagmx 2y ago
    It’s a bit much to say their primary product that they’ve done for decades is a plan B. By definition it cannot be a plan B if it’s executed first and is successful. I think a lot of RISC-V advocates are perhaps a little too over eager in their perception of the landscape.
    - snvzz 2y ago
      Typo. Meant to write "ARM is the plan A that they'll likely end up abandoning".
- mkl 2y ago
  Qualcomm has been working on RISC-V for a while, at outwardly-small scale. It's probably intended as a long-term alternative rather than a ready-to-go plan B. From a year ago: "The most exciting part for us at Qualcomm Technologies is the ability to start with an open instruction set. We have the internal capabilities to create our own cores — we have a best-in-class custom central processing unit (CPU) team, and with RISC-V, we can develop, customize and scale easily." -- https://www.qualcomm.com/news/onq/2023/09/what-is-risc-v-and-why-were-unlocking-its-potential https://www.qualcomm.com/news/onq/2023/09/what-is-risc-v-and..., more: https://duckduckgo.com/?q=qualcomm+risc-v&t=fpas&ia=web https://duckduckgo.com/?q=qualcomm+risc-v&t=fpas&ia=web
  - hajile 2y ago
    Qualcomm pitched a Znew extension for RISC-V that basically removes compressed (16-bit) instructions and adds more ARM64-like stuff. It felt very much like trying to make an easier plan B for if/when they need/want to transition from ARM to RISC-V. https://lists.riscv.org/g/tech-profiles/attachment/332/0/code_size_extension_rvi_20231006.pdf https://lists.riscv.org/g/tech-profiles/attachment/332/0/cod...
- brucehoult 2y ago
  Qualcomm have a Plan B. This time last year they were all over the RISC-V mailing lists, trying to convince everyone to drop the "C" extension from RVA23 because (basically confirmed by their employees) it was not easy to retrofit mildly variable length RISC-V instructions (2 bytes and 4 bytes) to the Aarch64 core they acquired from Nuvia. At the same time, Qualcomm proposed a new RISC-V extension that was pretty much ARMv8-lite. The proposed extension was actually not bad, and could very reasonably be adopted. Dropping "C" overnight and thus making all existing Linux software incompatible is completely out of the question. RISC-V will eventually need a deprecation policy and procedure -- and the "C" extension could potentially be replaced by something else -- but you wouldn't find anyone who thinks the deprecated-but-supported period should be less than 10 years. So they'd have to support both "C" and its replacement anyway. Qualcomm tried to make a case that decoding two instruction widths is too hard to do in a very wide (e.g. 8) instruction decoder. Everyone else working on designs in that space ... SiFive, Rivos, Ventana, Tenstorrent ... said "nah, it didn't cause us any problems". Qualcomm jumped on a "we're listening, tell us more" from Rivos as being support for dropping "C" .. and were very firmly corrected on that.
  - wmf 2y ago
    Dropping "C" overnight and thus making all existing Linux software incompatible is completely out of the question. Android was never really Linux though.
    - refulgentis 2y ago
      This is officially too much quibbling, even if we settled philosophical questions like "Is Android Linux?" Then "If not, would dropping C make RISC nonviable", there isn't actually an Android version that'll do RISC anywhere near on the horizon. Support _reversed_ for it, got pulled 5 months ago
      - snvzz 2y ago
        >Support _reversed_ for it, got pulled 5 months ago Cursory research will yield that this was a technicality with no weight in Google's strong commitment to RISC-V Android support.
- snvzz 2y ago
  It would be naive to think that Qualcomm is only starting its RISC-V effort today and from scratch.

bhouston 2y ago

Most people do not realize how slow RISC-V is right now. Yes, it will definitely get better, but it will take some time given how far behind it is. Like 30x slower than a top of the line Apple Mx series CPU. Maybe there is a high performing RISC-V chip out there but I haven't yet run into one. RISC-V benchmarks: https://browser.geekbench.com/search?q=RISC-V https://browser.geekbench.com/search?q=RISC-V. Compare to an Apple M4 benchmark: https://browser.geekbench.com/v6/cpu/8224953 https://browser.geekbench.com/v6/cpu/8224953 That said, RISC-V is good for embedded applications where raw performance isn't a factor. I think no other markets are yet accessible to RISC-V chips until their performance massively improves.

tightbookkeeper 2y ago
Is it slower by design or just because it’s implementations have not been aggressively optimized?
- bhouston 2y ago
  I believe it is just lacking aggressive optimization. ARM is basically RISC as well, so it isn't an architectural limitation.
  - tightbookkeeper 2y ago
    (Naive question) then is it really a big hurdle for a company who knows how to make arm chips to try making riscv chips?
    - bhouston 2y ago
      I suspect not? I think the principles and methods of optimization are the same. But I say this as a software guy who doesn't actually know CPU design.
    - 1123581321 2y ago
      It’s not a big hurdle so long as they hire Jim Keller to rapidly improve yet another architecture. (Only half-joking.)

dagmx 2y ago

Maybe fine for Android but this will set their windows plans back another decade if it happens It has taken them that long to make arm be a thing on windows and that’s building on people porting stuff to arm for Mac to finally get momentum. RISC-V with windows will be an eternity to be feasible.

snvzz 2y ago
>RISC-V with windows will be an eternity to be feasible. Will it now? Microsoft was already deeply involved in 2021 as per that years' summit RISC-V Foundation's technical talks. Ztso was pushed by them.
- dagmx 2y ago
  Whether Microsoft has windows running on an architecture is a very different level from whether it’s feasible to use it as a daily driver on windows. The ecosystem is what matters for most people. Windows for arm hails back to 2011. They’re only just now getting native arm ports for several major packages. That’s ~13 years for a well established architecture that’s used much more universally than RISC-V. They don’t even have arm ports for lots of software that has arm ports on macOS. RISC-V will take an aeon longer to get a respectable amount of the windows ecosystem ported over.
  - snvzz 2y ago
    >The ecosystem is what matters for most people. Absolutely agree. The key development Microsoft has demonstrated recently is the ability to run x86 Windows software in non-x86 Windows systems. Now that this is in place -and will only get better-, there is no longer a chicken and egg situation. Instead, what we have is a clearly defined path to migrate away from x86.
  - Atotalnoob 2y ago
    Arm on windows may date to 2011, but it was mostly a side project with 1-2 maintainers. With sufficient investment, it shouldn’t take 13 years to build up RISC-V support.