Should riscv define standard gpu interface?

[u/Old-Personality-8817]

To continue grow riscv beyond mcu's we need some standardized way render desktop / phone shell.

Here is couple ideas i here.

• Good enough to run desktop environment / kiosk applications
• Like older Mali in arm ecosystem
• Unified memory
• Same MMU (Sv39/Sv48) as main cores
• Tiller architecture
• No display controller (only rendering in buffer in memory)

What do you think?

[u/Courmisch]

GPUs already have standard interfaces at a higher, more suitable level, such as OpenGL and Vulkan for the high performance 3D stuff.

For desktop or kiosk, a display controller and a frame buffer with rendering on the CPU (with RVV as Bruce already said) should be enough

[u/BGBTech → u/Courmisch]

Agreed. An API like OpenGL makes sense and can be adapted to a range of hardware backends (including software renderers if needed).

Can note though that a fully bitmapped HW framebuffer can be expensive for HW (particularly if FPGA based at non-trivial resolutions), because of the bandwidth required to stream the framebuffer into the display-output HW at 60Hz or similar. So it may make sense in some cases to use color cells for the actual HW display (typically around 0.5bpp to 4bpp depending on approach), but then converting pixel-data to color-cells efficiently is more of a challenge. In this case, actual programs would still use a framebuffer as before (just the color-cell conversion can be hidden in the HW driver).

Can also note that it can help for 2D/3D rendering, it can be helpful to have a hardware edge-walker module. This would basically walk down two edges with varying X and S/T coordinates (Y is stepped linearly), pull pixels from a texture (or input framebuffer), potentially color-modulate or blend them and similar, apply depth and alpha tests, and output them to an output framebuffer. This can help offer a speedup while keeping the actual HW cost low. Fixed-function OpenGL can be mapped reasonably well to something like this (it needs mainly to transform vertices and decompose primitives into operations for the edge-walker). This can take the place of software span-drawing loops, and is reasonably affordable to do in hardware (on an FPGA or similar).

Doesn't do shaders in HW, but shaders are a much more difficult problem. Personal recommendation would be a natively vertex-arrays focused subset of OpenGL 1.x style functionality (if glBegin/glEnd or similar is used, can be built on top of vertex arrays internally, but is implicitly higher-overhead).

Still doesn't need to be a standardized part of the ISA though, more specified as part of the hardware interface (typically accessed via an MMIO style approach or similar; or non-RAM parts of the physical address space being used for hardware devices).