> remains to be seen how performant the GPU is

I think this is going to be the real make-or-break thing about RISC-V: early tests have shown super impressive SIMD/vector benchmarks compared to ARM/x86, but whether or not that will make it into production is another question entirely. I've got high hopes for RISC-V, but it's acceleration/HPC workload performance is going to determine whether it topples ARM or becomes the next Itanium.

Unlike Itanium, RISC-V is an ISA and there are many many different implementations of the ISA. You cannot conclude anything about the former based on a few instances of the latter. Patience.

I'm not deep in on this stuff, but isn't Itanium essentially the only implementation is IA-64? Presumably Intel was pushing the envelope on their implementation of the ISA.

According to https://en.wikipedia.org/wiki/Itanium this is actually clear as mud and it seems Itanium was both a family of implementations as well as ISAs (thus variants of IA-64?). It's also the _only_ implementations of IA-64.

Going back to the original question (can RISC-V "become another Itanium"?), as long as there are people using/support/evolving it. Unlike Itanium, RISC-V has the support very many companies already and the membership list of RISC-V International just keeps growing.

The only thing that could threaten it would be a better alternative appeared or if x86 or Arm suddenly got the same unrestricted license. The former is not impossible, but it would be huge undertaking and by definition we would be in a better place. The latter seems essentially impossible.

As there's no technical reason why a RISC-V implementation couldn't have roughly comparably performance to an Arm core (iso-effort and technology) it's "simply" a matter of sufficient investment before we'll have the X1 etc equivalents. There are very many companies working on high performance implementations. One of the high profile ones is Rivos, but there are _many_ others.

The Jetson nano being stuck on Ubuntu 18 is quite a shame...

I think they released the drivers so you could make your own JN compatible distro, not open-source, so I guess you are stuck with an old kernel...

The nvgpu/tegra drivers are all open source and GPL (nvgpu for Tegra has been open source for a long time) but they were until recently on an old 4.19 kernel. The latest is 5.10. There's also the usual firmware binary blob stuff as everyone else. There are rumors about them working on mainline support for the Orin SOC, and Orin is (AFAIK) designed primarily to use UEFI as its boot mechanism. So it may be looking a lot better soon as far as full custom distros are concerned. The userspace is still all closed, however.

I suspect a lot of the push for upstreaming (and the original Tegra GPU drivers being GPL) is from their automotive/industrial customers who want continuity guarantees.

> The userspace is still all closed, however.

What does this mean, can OpenGL not access the hardware without the userspace stuff?

and it is EOL...

So what?

The hardware that was sold could still work perfectly fine instead of having to be trashed if only the existing drivers were recompiled, to run on a recent distribution.

There's a PCIe slot, and thus there's nothing in the way of using a RDNA2 card from AMD, should the imatech GPU performance prove insufficient.

I guess, but for consumer friendly, low power and cost; it's better if it's all included.

Yes, and Imagination Technologies has been around for a while, designing, among other things, embedded GPUs (dating back to PowerVR days).

They've always had nasty drivers and no documentation, but this is apparently changing, with some new mesa driver funded by the company itself announced recently.