I phrased it incorrectly. The work is not done necessarily by the mesa project, but within its framework. The degree of activity of each project varies.

Mali 400 (Allwinner A20) https://github.com/yuq/mesa-lima

Adreno 2xx, 3xx, 4xx https://github.com/freedreno https://mesamatrix.net/

VC4 (Raspberry Pi) https://github.com/anholt/mesa/wiki/VC4

If the VC4 or Mali driver mature, then that'd be a huge step forward.

I've said it before, but I'd like to see LLVMpipe get a risc-v back end. And when the vector extensions are ready, support for that. This way all the SoC vendors should be able to implement basic frame buffer support with HDMI and use extra risc-v cores in place of a GPU. It wouldn't be fast, but it should be enough for things like a composited desktop and would provide minimal OpenGL support. Also, some guys have done a 500 core risc-v chip so maybe it doesn't have to be a poor performer. Intel got decent performance from Larabee right?

edit: the point is that many companies don't have any graphics IP, so this would give them a compromise.

Isn't a contemporary nvidia GPU essentially a vector machine with predication and scatter/gather? In CUDA it's just hidden behind the "SIMT" programming model.

If so, there's no fundamental reason why you couldn't make a decent GPU based on risc-v + the vector extension. Just make the cores themselves relatively modest, no reason to waste die area on OoO logic, and have lots of hardware threads to drive memory parallelism. Oh, and gobs of memory BW.

Though IIRC Intel had to have some fixed function blocks, and IIRC other GPU's also have some of them left.

I also recall reading about Larrabee suffering from a lot of internal BW being wasted on cache coherency traffic, but with risc-V having a weaker memory consistency model perhaps that would be less of a problem for a hypothetical "risc-v gpu"?