This looks like it has fairly similar goals and implementation choices as RV64X. I didn't immediately see them citing that previous work, but I've only skimmed it so far. In any case, I love seeing work like this.
Too late to edit: I was confusing RV64X and Vortex. It is indeed based on the latter, and extends it in interesting directions, in particular implementing Vulkan instead of just OpenGL.
SIMT is interesting because each thread looks like scalar code but multiple threads are executed in lockstep using parallel pipelines. They only had to add a few instructions (section 2.3) to enable RISC-V to support SIMT.
But I suppose that SIMT-oriented cores also need to disable some instructions, like most jump instructions, and especially jumping back, correct? Also, I suppose, there ought to be an easy way to look into the memory "to the left" and "to the right", but likely it can be preset by making a constant offset available to every thread.
Typically in SIMT, all lanes in a "simd" (aka subgroup in Vulkanspeak) share the same program counter. However, there is an execution mask so not all lanes are active. Thus, to simulate "if A then B else C", you evaluate A for each lane to derive a mask, jump to C if the mask is empty, evaluate B only for the enabled lanes, invert the mask, skip over C if the mask is then empty, and evaluate C only for the enabled lanes. Loops also work, with similar logic (the real loop terminates when the predicate is false for all lanes).
SIMT control flow can get tricky. Unconditional jumps are fine if all the threads jump to the same address (e.g. a function call or return) because they're still in lockstep. Data-dependent conditional branches cause divergence (some threads branch and some don't) which requires special handling mentioned in the paper.
That was exactly what came to mind as well. "Big" RISC-V performance oriented cores for apps, gobs of "small" RISC-V cores ganged together for GPU. Larrabee didn't work out so good, though.
Skybox is closer to the old 1970s-1980s SIMD machines like ILLIAC and the Connection Machine or (I think) the current NVIDIA, it has two sets of added instructions, one has to do with managing multiple ‘wavefronts’ (like threads) that run the same instructions with the possibility of turning some off (predication, which was deliberately left out of RISC-V, would have been a help). The other instruction control fixed function units and do fused integer multiply-adds. I don’t see any talk about vector instructions.
In a similar vein, two decades ago there was the Sony/Toshiba/IBM Cell processor which ganged up a general-purpose PowerPC core with a cluster of lightweight co-processing PowerPC cores called SPEs:
The idea was that Cell would also act as the GPU for the PlayStation 3, but performance wasn’t good enough when the chip was finally ready, so they ended up complementing it with an Nvidia GPU.
The programming model was quite difficult. The SPE cores couldn’t directly access main memory. Instead they had small local SRAM buffers (256kB I believe) that the programmer would manually fill using explicit DMA commands either from other SPEs or from main memory. Orchestrating these memory operations for high performance must have been a chore, and when you do have the data, then you have to deal with the SPE having a different architecture with no branch prediction, etc.
GPUs and CUDA turned out to be a much more palatable model for general-purpose compute.
With some evolution, coders adapted to this model and found approaches that both worked well and even abstractions that made working with the SPEs both effective and not as much of a chore. In an interesting turn of events it turns out that if you could architect the SPEs to perform well the same basic approach helped unlock multi core performance on x86-64.
Best I can tell from skimming, it looks like the command processor and the grid of compute cores both probably use a RISC-V ISA, and the "shader cores" have some custom extensions.
It looks very cool, I wonder if they published the RTL anywhere.
Even CPUs without any vector instructions at all can still do operations on vectors; they just have to do them "the hard way": slowly. This worst case ain't the end of the world if each core is fast enough and you have enough cores.
In this case, the design (AFAICT) uses RISC-V's support for extensions to add some GPU-specific instructions for things like vector math and texture lookups.
RISC-V has GPU vector extension in order to build "shader" cores.
But this is not a hardware 3D pipeline. In theory, the hardware 3D pipeline should be programmed "à la" vulkan: hardware queues of commands (3D/compute/DMA).
But as far as I know, we don't have something like ahci or nvme or usb xhci for that... yet.
GPUs aren't necessarily synonymous with "super dense vector machines that happen to be good for graphics workloads". A linear frame buffer with a dedicated RISC-V core for drawing primitives can be called a GPU, too.
That's not a silly question, it's in fact very questionable how much "RISC-V" would be left if you really tried to mold it into a traditional GPU design (nvidia, amd, powervr, etc.)
There is some kind of bottleneck shown in Table 4 and I can't see what it is by reading the text in section 7. The IPC/core drops from about 2.5 to 1.5 for the same stall rate at the number of cores is increased?
