this post was submitted on 19 Jun 2024
715 points (98.6% liked)

Technology

59605 readers
3501 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] synapse1278@lemmy.world 106 points 5 months ago (8 children)

RISC-V (pronounced risk five), is a Free open-source Instruction Set Architecture (ISA). Other well established ISA like x86, amd64 (Intel and AMD) and ARM, are proprietary and therefore, one must pay every expensive licenses to design and build a processor using these architectures. You don't need to pay a license to build a RISC-V processor, you only need to follow the specifications. That doesn't mean the CPU design is also free, no, they stay very much the closed property of the designer, but RISC-V represents non the less, a very big step towards more transparency and technology freedom.

[–] msage@programming.dev 1 points 5 months ago (3 children)

Isn't it possible to add custom instructions and locking others from them, leading back to the current ARM situation?

[–] synapse1278@lemmy.world 1 points 5 months ago (1 children)

I know there are already a number of extensions specified in the specifications, such that Risc-V could be relevant to design the simplest of microcontroller up to the most powerful super computer. I suppose it is possible and allowed to design a CPU with proprietary extensions. What should prevent an ARM type of situation is the fact that so many use-cases are already covered by the open specifications. What is not there yet, to my knowledge, are things like graphics, video, neural-net acceleration.

[–] barsoap@lemm.ee 1 points 5 months ago

graphics, video, neural-net acceleration.

All three are kinda at least half-covered by the vector instructions which absolutely and utterly kills any BLAS workload dead. 3d workloads use fancy indexing schemes for texture mapping that aren't included, video I guess you'd want some special APU sauce for wavelets or whatever (don't know the first thing about codecs), neural nets should run fine as they are provided you have a GPU-like memory architecture, the vector extension certainly has gather/scatter opcodes. Oh, you'd want reduced precision but that's in the pipeline.

Especially with stuff like NNs though the microarch is going to matter a lot. Even if a say convolution kernel from one manufacturers uses instructions a chip from another manufacturer understands, it's probably not going to perform at an optimal level.

VPUs AFAIU are usually architected like DSPs: A bunch of APUs stitched together with a VLIW insn encoder very much not intended to run code that is in any way general-purpose, because the only thing it'll ever run is hand-written assembly, anyway. Can't find the numbers right now but IIRC my rk3399 comes with a VPU that out-flops both the six arm cores and the Mali GPU, combined, but it's also hopeless to use for anything that can't be streamed linearly from and to memory.

Graphics is the by far most interesting one in my view. That is, it's a lot general purpose stuff (for GPGPU values of "general purpose") with only a couple of bits and pieces domain-specific.

load more comments (1 replies)
load more comments (5 replies)