RISC-V has no PI lock like ARM or x86 and x86_64.

RISC-V has to start to seriously defend itself, because it is a death sentence for ARM ISA and and could start to cast shadows on x86_64 in some areas slowly but surely. Some people will try to bring it down, hard.

If you stick to core rva22+ (core RISC-V ISA), RISC-V is good enough to replace all of them, without PI lock, and with a global standard ISA, software may have a chance to get out of the horrible mess it is currently in (a lot of critical software code path may end up assembly written... no compiler lock-in, extremely hard to do planned obsolescence, etc).

RISC-V is basically ARM ISA without PI lock.

I have been writting RISC-V assembly running on x86_64 with an interpreter for much of my software projects. It is very pleasant to code using it (basic assembler: no pseudo-instructions, I don't even use the compressed instructions).

I hope to get my hands on RISC-V performant implementations on near state-of-the-art silicon process some day (probably a mini-server, for all the self hosted stuff).

The 'silicon market' is saturated then it is amazing what the RISC-V supporters have been able to achieve. There will be mistakes (some probably big), before implementations do stabilize in the various domains (desktop/server/embedded/mobile/etc), and expect the others to press hard on them.

The next step for RISC-V would be a GPU ISA, and for RVAX, a standard hardware GPU programming interface... but it may be still too early for that since we kind of still don't know if we reach 'the sweet spot'.

▲

thecosmicfrog 3 days ago | parent | next [-]

What is "PI lock"? A cursory web search didn't reveal much.

	▲	sylware 2 days ago \| parent [-]
		IP lock, my bad (in my native language it is the other way around). Intellectual Property lock. ARM, x86(intel), x86_64(amd) have such extremely strong locks in countries where those are legal to be enforced. It is said they literaly deny anybody else to use their ISAs unless there is a super strong power struggle and/or a giga-enormous amount of $$$ in the bargain.

▲

sylware 2 days ago | parent | prev [-]

Oh, regarding GPUs, AMD started to experiment on userland _hardware_ ring buffers... I don't know how they will handle their scarse VM id resources... the kernel may end up "only" mmaping event/command ring buffers and data dma/doorbells buffers with an "IRQ" event file descriptor.

We are talking a "near 0-driver"... but they will have to be very confident in their GPU robustness to do that, not to mention 3D pipeline programming from those userland _hardware_ buffers will have to be really simple and directly "ready" to work.