Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

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)?

View on HN

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).

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

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.

Vector instructions are a type of SIMD

I think SIMD referred to Intel SSE*/AVX/etc., where the vectors are of fixed length. That meant new instructions had to keep getting introduced for new sizes of vectors.

SIMD as a term predates those Intel instructions by 30 years.

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.

> AVX style vectors IMHO should have been used for all those vec3 and vec4 operations that are used in graphics applications.

That is the naive application of SIMD, which many have attempted. It does not lead to a meaningful speedup.

To get a good speedup from SIMD, you need SOA or AOSOA layout. Ergonomically this is already similar to vector instructions.

>> That is the naive application of SIMD, which many have attempted. It does not lead to a meaningful speedup.

How can it not provide a meaningful speedup? If I have 3- or 4-element vectors a,b, and c, with scalars u,v. I want to compute:

a = ub + vc;

These should be first class data types, passed by value, and that line of code should take 2 SIMD instructions at most. That should also not require a fancy vectorizing compiler to do the analysis to find the parallelism because the data types map directly to the ISA vector registers.

GPUs have this, the benefit should be very real.

By and large, GPUs don't have this anymore, actually (they used to, but this changed many years ago). On modern GPUs your example is "scalarized" and results in separate instructions for each vector component. Of course execution is still "vectorized", but only in the sense of operating on the data for 16/32/64 threads at once.

The reason for this design is that while vec3 and vec4 are common, they are by no means universal in modern shader code. A micro-architecture built on vec3 or vec4 would be under-utilized in the large amounts of shader code that are scalar in the source language.

There are some exceptions, e.g. native support for 16-bit vec2 comes naturally on architectures with 32-bit registers. But those are exceptions.

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.

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.

From a high enough level they are architecturally similar. But these x86 cores don't scale _down_ to 500-1000 logic elements per core.

This is an architectural level, not a microarchitectual level design (yet).

Reply on news.ycombinator.com