RV64X: A Free, open-source GPU for RISC-V

https://www.eetimes.com/rv64x-a-free-open-source-gpu-for-risc-v/

by mardiyah • 5 years ago

188 50 5 years ago

I'm not clear: Is this proposing that we make risc-v CPUs that also perform the work of a GPU, or is this a way to make a risc-v GPU (standalone)?

oregontechninja• 5 years ago

It looks like you could have C+GPU cores. I bet you could still split the gpu portion out into its own separate thing if you wished.

Zenst• 5 years ago

Somehow this all reminded me of https://en.wikipedia.org/wiki/Larrabee_(microarchitecture)

It's the whole - full core on a GPU aspect, which probably isn't a bad idea for a few reasons, could even offload much of the driver onto it and with that, make platform drivers much more manageable...maybe.

xiphias23• 5 years ago

SIMD instructions were a mistake in CPU instruction set design.

Vector instructions have register size independent code which makes vector programming from CPUs much more approachable and binary compatible.

zeckalpha4• 5 years ago

Vector instructions are a type of SIMD

phkahler2• 5 years ago

AVX style vectors IMHO should have been used for all those vec3 and vec4 operations that are used in graphics applications. They should not have been used for general parallelization of loops - although they have had some success in that.

GPUs have geometrically relevant vectors as basic data types. I wish language designers would realize the value in that, but they are too concerned with abstraction.

RISC-V vectors are meant for the abstract general parallel concepts, but could also help with graphics code.

There really seems to be a disconnect around which types of vectors are good for which uses.

hajile• 5 years ago

You’d have two separate sets of cores. The general purpose cores will have all the usual extensive you’d expect.

Meanwhile, the GPU cores will be simple cores with huge vector engines. This honestly seems somewhat similar to RDNA at a high level where you have a large SIMD unit with a scalar cores for branching and one-off calculations.

The big payoff is cohesiveness. Your RISC-V GPU shares the same memory model as your CPU. This should have a payoff in easy integration. Likewise, sharing a good permission model can probably help with all those GPU exploits in third-party code (like webGL).

avocactus57• 5 years ago

In terms of similarity with RDNA, you mean large cache memory which can store bigger matrixes?

xiphias23• 5 years ago

The article doesn't write about mixed precision machine learning. Will it be available? I would really love to see a RISC-V laptop using vector extensions beating the Apple M1 core in everything (though I know that it will take a lot of time to get to 5nm process node).

ece2• 5 years ago

It mentions support for INT8 for ML/AI. FP16 and BF16 support isn't explicitly mentioned, but it does support 8/16/32-bit fixed/float scalars and vectors, so it could be added later.

xiphias23• 5 years ago

So the answer is no :(

Anyways I expect RISC-V to appear in Chinese mobile phones before laptops as the main unit.

It would be fun to run Android on this RV64X architecture....I guess that's the goal.

girvo• 5 years ago

I wonder what company would put in the hundreds of millions to design a RISC-V processor on 5nm? I’m not being facetious — I wonder if there will be a future where we see that! It would be super exciting.

samus3• 5 years ago

Chinese companies will take that step for sure once China manages to bring domestic advanced nodes into production. It doesn't make sense to have domestic semiconductor and then use a proprietary ISA like ARM or x86(_64) again.

meekrohprocess• 5 years ago

Very cool. It's interesting that they are planning to start with Vulkan support, followed by OpenGL/DX/etc.

I guess it makes sense; the RISC-V crowd might possibly skew towards early adoption over backwards-compatibility.

It would be really cool to see some implementations from places like SiFive/GigaDevice/etc. Imagine how easy driver support could be if everyone used and contributed to the same open IPs...

moonchild• 5 years ago

They can also take advantage of zink to implement opengl, at least on platforms that support mesa; and use wine's implementations of direct3d.

I expect that, in the future, gl and d3d will be implemented entirely on top of vulkan, and thus be more portable and make it easier to make GPUs and graphics drivers.

mrec• 5 years ago

I expect that, in the future, gl and d3d will be implemented entirely on top of vulkan

I'm not sure whether you're talking about the "official" Microsoft D3D libs here, but I very much doubt that'll ever happen. They don't like dependencies they can't control. The Excel team used to maintain their own compiler because they didn't want to be dependent on the Visual C++ team who worked in the same building.

Same with Apple and Metal.

asiachick• 5 years ago

If they wanted to provide OpenGL ES support (all mobile devices) they could just use ANGLE which will provide OpenGL ES support on top of vulkan

https://github.com/google/angle

pjmlp4• 5 years ago

All mobile devices means only up to version 2.0.

Version 3.0 is the latest on iDevices and while Android can do up to 3.2, it is an optional API.

Likewise, Metal is the name of the game on iOS nowadays, and Vulkan was introduced in Android 7 as optional API, and only became mandatory in Android 10.

Vulkan also carries on the tradition of Khronos APIs, extension spaghetti, so while a device might support Vulkan, it doesn't mean it supports the Vulkan that the application actually needs.

https://vulkan.gpuinfo.org/listdevices.php?platform=android

userbinator2• 5 years ago

Prevous attempts at taking a regular CPU architecture and turning it into a GPU haven't worked so well --- it's what Intel attempted many years ago --- so I'm not too optimistic about how this will turn out. Then again, the boring and uniform nature of RISC-V may be more suitable to mass parallelisation in a GPU than as a CPU.

The name is slightly reminiscent of https://en.wikipedia.org/wiki/File:RIVA_TNT2_VANTA_GPU.jpg

zeckalpha4• 5 years ago

This doesn’t quite seem like that as the implementation of the instructions isn’t yet specified. Even if it is integrated, it can use dedicated VRAM and not have to use the CPU’s ALU.

anp• 5 years ago

FWIW, NVIDIA have been adopting RISC-V as the internal ISA for their GPUs: https://riscv.org/wp-content/uploads/2017/05/Tue1345pm-NVIDI.... It’s definitely a different architectural approach than described in OP though.

yaantc• 5 years ago

No, it's not the GPU ISA. Complex chips tend to embed management cores, for example to handle power management or various configuration operations across the chip. NVidia used a proprietary ISA (Falcon) for such cores, and moved to RISC V. But this is independent from the GPU ISA itself, which remains NVidia proprietary. So in the end, in their embedded SoC you can find (at least) 3 ISAs: ARM for CPU, NVidia proprietary for the GPU, and RISC V for NVidia management cores. And it's likely there are more, for example for audio DSP and other IPs embedded programmable units.

djmips• 5 years ago

It's not the internal ISA of their GPU but of a CPU they use in their designs.

samus3• 5 years ago

From what I researched, Falcon is used on nVidia GPUs for everything _but_ the graphics, for example to enforce a security model. But it's a start. Probably they will start using for other purposes as well, for example video encoders and decoders. I very much doubt though they will scutte their existing GPU architectures for RISC-V yet.

dragontamer• 5 years ago

Every attempt to do what other people have failed at benefits from hindsight.

There's been one major success case: A64Fx and ARM SVE. The Fujitsu processor just recently took #1 in LINPACK, #1 Green500 (also the most efficient) and also #1 in HPCG (an alternative benchmark that GPUs traditionally suck at).

Its not a full GPU yet, but that A64Fx is clearly a powerful SIMD compute cluster, very similar to a GPU. It has succeeded where the Xeon Phi seems to have failed.

atq21193• 5 years ago

It's unclear that this particular project has learned from Larrabee hindsight. The graphics part of the GPU doesn't seem to be thought through at all.

That said, if the goal is to compete with existing GPUs for general compute workload, the graphics part is unnecessary anyway. That could work out, though calling it a GPU is a red herring.

nynx• 5 years ago

I'd like to see more MIMD or MISD architecture exploration. 2048 core basic riscv processors anyone?

villgax2• 5 years ago

Wish GPUs came with upgradable RAM slots like SODIMMs in laptops

userbinator2• 5 years ago

They used to, some of them in the 90s had expandable VRAM:

https://upload.wikimedia.org/wikipedia/commons/f/f8/DIAMONDS...

https://upload.wikimedia.org/wikipedia/commons/6/6b/Matrox_M...

http://vgamuseum.info/images/palcal/profi/665_elsa_xl_top_hq...

dathinab• 5 years ago

After apple setting a precedence with packaged RAM I fear in the future upgradeable RAM might become rare on everything but high end workstations.

I hope this will not happen, but especially certain laptop companies always wanted to have non upgradeable RAM and only stepped back because users where to unhappy about it. But now they will point to Apple and tell you that's necessary for fast low power laptops with long battery live.

pjmlp4• 5 years ago

What precedence?

Do you think we could extend the memory of most 8 and 16 bit home computers?

If we wanted to upgrade our computers, beyond plugging stuff on the external expansion port, we had to buy a new model.

The PC was the precedence, and only due to IBM losing control of it.

Now with laptops and tablets becoming the standard consumer computers, we are back into the 80-90's computer form models, just instead of plugging them into the TV, the screen comes along for the ride.

And actually it was great, because it meant developers had to learn to extract all the juice of the computers people had, instead of expecting us to spend money upgrading.

StillBored3• 5 years ago

Well given Apple doesn't appear to be gaining a latency advantage from their ram on package the jury seems to still be out on that theory.

OTOH, the trend has been to put HBM/edram/etc on package for a while. Various intel/etc products have done that, which provides a fast tier of memory that you put in a local NUMA domain. Then put the actual DRAM in its own domain.

The problem so far is that strategy doesn't actually work well for most applications because they aren't sufficiently NUMA aware to take advantage of it. Instead what ends up happening is the "fast" ram ends up being a LLC tier.

It all ends up sorta being a physics thing though, it seems as you increase capacity, distance tends to grow as well. Meaning that there will be a limit to how much RAM they can toss on package and still gain a latency advantage over just soldering it to the board.

zeckalpha4• 5 years ago

SoCs are the future, much lower latency. Perhaps the SoC can be upgradable like the Raspberry Pi CM.

phendrenad2• 5 years ago

It'll be interesting to see if this goes the Larrabee route (a flat array of CPUs which share everything) or the traditional GPU route (multiple levels of shared resources).

airocker• 5 years ago

Naive question but can you not target just one use case: ml, graphics etc to begin with? Something like tpu? Why does it need support every use case of a gpu in the initial design?

samus3• 5 years ago

Multiple reasons might apply:

- Focusing on one use case might make it difficult to generalize the design later. Lessons learned might not carry over, and the platform will get anchored into particular design choices. This only gets worse the more the solution gets deployed.

- Having a product that can do both makes it simpler to do applications that combine multiple computational loads. Else, the data has to be transferred to another device. This seems unattractive since graphics, ML and massively parallel scientific computations are more similar to each other than to what CPUs are used for.

- Development budget gets fragmented, which is a disadvantage since the different use cases might not correspond to markets that are large enough to support each product.

- One of the platforms might just die off. Users that use both would be stuck in between and would have to find a solution, and most likely it will be NVidia/AMD again.

RV64X: A Free, open-source GPU for RISC-V

Related Stories