RISC‑V Based Open‑Source GPU Architecture (RV64X)

A collective of engineers is advancing a novel set of graphics instructions optimized for 3D rendering and media processing. These instructions extend the RISC‑V base vector ISA with graphics‑specific data types and layered extensions, covering vectors, transcendental math, pixel manipulation, textures, and Z/frame‑buffer operations. The proposal, named RV64X, uses 64‑bit instructions to deliver a robust, unified CPU‑GPU ISA.

Why now?

Commercial GPUs excel at mainstream workloads but often fall short for niche tasks such as dual‑phase 3D frustum clipping, adaptable HPC (e.g., arbitrary‑bit‑depth FFTs), and hardware SLAM. A community‑driven, open standard can reduce the 10‑20‑year development cycle, foster cross‑verification, and provide flexible, scalable solutions for a broader range of applications.

The team’s vision is a compact, area‑efficient core that offers custom programmability and extensibility. It will be available as free, open‑source IP for both FPGA and ASIC targets, targeting low‑power microcontrollers initially. The design will be Vulkan‑compliant, with future support for OpenGL, DirectX, and other APIs.

The final hardware will be a RISC‑V core with an integrated GPU functional unit. To the programmer it presents a single 64‑bit instruction set; scalar opcodes are prefixed with vector context, enabling the compiler to generate SIMD instructions behind the scenes. The architecture supports variable issue, predicated SIMD, vector front‑end, precise exceptions, branch shadowing, and more. No separate RPC/IPC layer is required for CPU‑GPU communication. It will support 16‑bit fixed point (ideal for FPGAs) and 32‑bit floating point (ASICs or FPGAs).

The design leverages the Vblock format from the Libre GPU effort:

• Bit‑like VLIW structure that tags scalar instructions with register context
• Sub‑blocks provide vector length, swizzling, width overrides, and predication
• No dedicated vector opcodes; vector mode is activated when a scalar opcode references a vector‑tagged register
• Hardware‑level for‑loop execution of multiple contiguous scalar operations, implemented as SIMD, multi‑issue, or single‑execution depending on the vendor’s choice

Supported data types include 8‑, 16‑, 24‑, and 32‑bit fixed and floating point scalars, as well as transcendental functions (sincos, atan, pow, exp, log, rcp, rsq, sqrt, etc.). RV32‑V vectors support 2‑ to 4‑element operations with 8‑, 16‑, or 32‑bit elements, and specialized instructions for 3D graphics pipelines: points (XYZW), pixels (RGBA), texels (UVW), and material coefficients.

• XYZW points (64‑ and 128‑bit fixed and float)
• RGBA pixels (8‑, 16‑, 24‑, and 32‑bit)
• UVW texels (8‑, 16‑bit per component)
• Material parameters (Ia, ka, Id, kd, Is, ks…)

Native 2×2, 3×3, and 4×4 matrix support is included, stored as 4×4 for simplicity.

Benefits of a fused CPU‑GPU ISA include a microcode‑driven graphics pipeline, custom shader support, ray‑tracing extensions, and 8‑bit integer vector support for AI and machine‑learning workloads.

Custom rasterizers—such as spline‑based surfaces, subdivision patches, and bespoke tessellators—can be implemented. The architecture is fully configurable, enabling user‑defined pipeline stages, geometry/pixel/frame‑buffer operations, and instancing.

RV64X block diagram

The reference implementation will feature:

• 32 KB Instruction/Data SRAM Cache
• 8 KB Microcode SRAM
• Dual‑Function Instruction Decoder
  • Hardwired RV32V and RV64X support
  • Micro‑coded decoder for custom extensions
• Quad Vector ALU (32‑bit fixed/float)
• 136‑bit Register File (1 K elements)
• Special Function Unit
• Texture Unit
• Configurable local Frame Buffer

Scalability is built into the architecture, as shown below.

RV64X’s scalable design

Key innovations include a unified CPU‑GPU ISA, configurable registers for custom data types, and user‑defined SRAM‑based micro‑code for application‑specific extensions—custom rasterizer stages, ray tracing, machine learning, and computer vision.

The same core can serve as a standalone graphics microcontroller or a scalable shader unit, supporting both FPGA‑native and ASIC implementations.

Why open‑source graphics?

Current GPUs primarily target high‑end markets—gaming, HFT, vision, and ML—leaving a gap for mainstream devices like kiosks, billboards, casino gaming, toys, robotics, wearables, industrial HMI, infotainment, and automotive clusters. An open, scalable graphics core for RISC‑V would reduce multi‑language burdens and spur innovation across these domains.

Next steps

The specification is early and evolving. The team plans to launch a discussion forum, build an instruction‑set simulator, and develop an FPGA prototype using open‑source IP. Benchmarks and demos are in progress. Interested developers should contact Atif Zafar to join the effort.

In parallel, the Libre‑RISC‑V 3D GPU initiative aims to create a hybrid CPU/VPU/GPU SoC—not a dedicated GPU—providing a complete, Libre‑licensed processor for a variety of embedded applications.

Industry Context

The GPU ecosystem now includes over a dozen major players: Apple, Qualcomm, AMD, Nvidia, Arm, Intel, Think‑Silicon, DMP, Jingjia Micro, VeriSilicon, Imagination Technologies, and the emerging RISC‑V Graphics community.

Potential use cases for a free, flexible GPU extend beyond graphics, encompassing cryptocurrency mining and other compute‑heavy workloads.

Adoption is likely to take at least two years. Xilinx, which currently integrates Arm’s Mali in its Zynq line, and several Chinese vendors are plausible early adopters.

► This article was originally published on our sister site, EE Times.

For more embedded content, subscribe to Embedded’s weekly email newsletter.