There's A New Libre GPU Effort Building On RISC-V, Rust, LLVM & Vulkan

[phoronix]

Phoronix: There's A New Libre GPU Effort Building On RISC-V, Rust, LLVM & Vulkan

Over the past decade and a half of covering the Linux graphics scene, there have been many attempts at providing a fully open-source GPU (or even just display adapter) down to the hardware level, but none of them have really panned out from Project VGA to other FPGA designs. There's a new very ambitious project trying to create a "libre 3D GPU" built atop RISC-V, leveraging Rust and LLVM on the software side, and would also support Vulkan...

http://www.phoronix.com/scan.php?page=news_item&px=Libre-GPU-RISC-V-Vulkan

[tildearrow]

They missed the video out part though.

This may work well if the processor has a lot of cores...

[HadrienG]

...and wide vectors with good gather/scatter and predication. That's the first source of parallelism in modern GPUs (though "real" cores, like what NVidia calls SM, are slowly getting close).

[microcode]

This is a similar setup to something that Esperanto Technologies said they had prototyped. There's really nothing about RISC-V that prevents you from using it as a GPU base ISA.

What I think would be interesting is an architecture which is not completely like most GPUs, which would basically be a set of full system cores with some graphics functionality, in addition to non-graphics cores. If your process uses the graphics functionality, it traps and is scheduled on a graphics-optimized core. These cores would have special stuff like MMU views to do interpolation and texture swizzles and decoding, datatypes appropriate for graphics available to vector runs. You'd still want fixed functions for rasterization, fragment blending, etc., but maybe a middle ground has some value.

[brent]

I'm not quite sure what to think of this, after the big failure that EOMA68 has been. The basic idea doesn't sound that great either: GPUs are efficient because of substantial amount of fixed-function, special-purpose hardware to accelerate common tasks like rasterization, texture sampling, geometry processing and now even raytracing. An array of general-purpose CPUs won't cut it.

[vegabook]

This is a similar setup to something that Esperanto Technologies said they had prototyped. There's really nothing about RISC-V that prevents you from using it as a GPU base ISA.

What I think would be interesting is an architecture which is not completely like most GPUs, which would basically be a set of full system cores with some graphics functionality, in addition to non-graphics cores. If your process uses the graphics functionality, it traps and is scheduled on a graphics-optimized core. These cores would have special stuff like MMU views to do interpolation and texture swizzles and decoding, datatypes appropriate for graphics available to vector runs. You'd still want fixed functions for rasterization, fragment blending, etc., but maybe a middle ground has some value.

Forgive my ignorance but isn't this what Xeon Phi was kinda like? 64c256t "general" cores with lots and lots of AVX thrown in?

[microcode]

Forgive my ignorance but isn't this what Xeon Phi was kinda like? 64c256t "general" cores with lots and lots of AVX thrown in?

Well, sorta, but no. Larrabee/Phi did not have rasterization and blending hardware, and as such is severely disadvantaged in standrad rasterized pipelines before we even get to the question of shaders. In addition, generally this "GPU" type hardware was still separate from your host application processor, whereas what I'm describing makes the same process capable of being scheduled onto and off of the graphics-oriented cores, without any fiddling about.

Also, I don't know and can't comment on swizzles and texture compression on Larrabee/Phi, but I suspect neither is supported, which further limits usefulness for realtime graphics.

[c117152]

There's really nothing about RISC-V that prevents you from using it as a GPU base ISA.

Quite the understatement considering one of the first, if not the first, risc-v implementations was nVidia's NV-RISCV as used in their GPUs following ~2016: https://riscv.org/wp-content/uploads...V_Story_V2.pdf https://riscv.org/wp-content/uploads...ijstermans.pdf

[Michael]

Quite the understatement considering one of the first, if not the first, risc-v implementations was nVidia's NV-RISCV as used in their GPUs following ~2016: https://riscv.org/wp-content/uploads...V_Story_V2.pdf https://riscv.org/wp-content/uploads...ijstermans.pdf

Well NV-RISCV was used as just a Falcon replacement in their control processor and not really for the graphics ISA.

[c117152]

Well NV-RISCV was used as just a Falcon replacement in their control processor and not really for the graphics ISA.

True. But that's most of the silicon logic anyhow considering the rest of the cores just do raw compute... no? I mean, there's a reason they insist on keeping the microcode closed and don't care about the rest being out there. I think?