Skybox: Open-Source Graphic Rendering on Programmable RISC-V GPUs | Hacker News Reader

Skybox: Open-Source Graphic Rendering on Programmable RISC-V GPUs

dl.acm.org

95 pointsPaulHoule34 comments

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.

Silly question: how can a GPU be RISC-V? Isn't RISC-V a normal "scalar" ISA with some moderate vector extensions at best?

Check out figures 1 & 5.

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.

It reminds me of https://en.wikipedia.org/wiki/Larrabee_(microarchitecture) - Intel wanted to make a GPU out of dozens upon dozens of tiny x86 cores. I think the idea was start building an x86 moat around CUDA (ha).

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:

https://en.wikipedia.org/wiki/Cell_(processor)

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.

Somewhere I have a CellBE PCI development board (from Mercury). I should get it working again and see if it's easier to deal with now.

Indeed and now AVX is what is left of it.

The idea was good, the execution not so much.

Reminds me of the transputer https://en.wikipedia.org/wiki/Transputer

One of the architects of Larrabee was very involved in RVV. He has some lots of good talks on Vector ISA stuff.

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.

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.

This makes much more sense now, thanks!

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.

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.

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

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.

If you take a look at widely deployed GPU ISAs (such as GCN/RDNA), you'll find they're RISC ISAs with some specialized instructions.

The graphics effort in RISC-V aims at providing a bunch of such specialized instructions in an official extension, suitable for GPU use.

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.

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

I was confused by this as well.

Then I learned GPU are basically a bunch mutli-core with each core having a vector extensions and what Intel would call 'hyperthreading'.

At least that how I think about it.

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?

Curious about that too - just overhead from multi-core handling in the code? I'd expect to see the stall rate increase if that was the case though.

Where is the source code, I'm confused. Maybe after the presentation?

Note this Skybox is unrelated to the geospatial imaging company that Google acquired in 2014 and then sold to Planet in 2017.

https://spacenews.com/planet-to-acquire-terra-bella-from-goo...

I'd like to ask how they made all the diagrams in this paper, they look great.

They look like Visio to me. Would be nice if they were from something else though.

Thanks. Can you suggest anything else?

https://app.diagrams.net/ is pretty ok

It could have also been done with LibreOffice (draw). But many tools can generate diagramms.

I can't find the actual repository, does anyone have a link?

Linking to a PDF? Please put that in the title.

Reply on news.ycombinator.com