SpacemiT K3 is an upcoming RVA23-compliant 64-bit RISC-V processor based on X100 cores clocked at up to 2.5 GHz. So far, we had limited information, but SpacemiT gave remote access to one SpacemiT K3-powered server to Sander, and he was kind enough to share some system information and early benchmarks.
Let’s start with system information reported by inxi utility:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
superkoning@spacemit:~/CNX$ inxi -Fc0 System: Host: spacemit Kernel: 6.12.16-generic arch: riscv64 bits: 64 Console: pty pts/0 Distro: Ubuntu 26.04 (Resolute Raccoon) Machine: Message: No machine data: try newer kernel. Is dmidecode installed? Try -M --dmidecode. CPU: Info: 16-core model: Spacemit X100 variant: riscv bits: 64 type: MCP cache: L2: 10 MiB Speed (MHz): avg: 2200 min/max: 614/2400:2000 cores: 1: 2200 2: 2200 3: 2200 4: 2200 5: 2200 6: 2200 7: 2200 8: 2200 9: 2200 10: 2200 11: 2200 12: 2200 13: 2200 14: 2200 15: 2200 16: 2200 Graphics: Device-1: saturn-edp driver: spacemit_drm_drv v: N/A Display: server: X.org v: 1.21.1.21 with: Xwayland v: 24.1.8 driver: N/A tty: 211x41 API: EGL v: 1.4 drivers: swrast platforms: surfaceless,device API: OpenGL v: 3.3 vendor: mesa v: 24.0.1 note: console (EGL sourced) renderer: softpipe API: Vulkan Message: No Vulkan data available. Info: Tools: api: eglinfo, glxinfo, vulkaninfo x11: xdriinfo, xdpyinfo, xprop, xrandr Audio: Message: No device data found. API: ALSA v: k6.12.16-generic status: kernel-api Server-1: PipeWire v: 1.4.9 status: active Network: Device-1: k3-gmac driver: dwmac_spacemit_ethqos IF: end1 state: up speed: 1000 Mbps duplex: full mac: fe:fe:fe:c6:37:53 Device-2: rfkill-gpio driver: rfkill_gpio Device-3: dwmac-5.10a driver: N/A IF: can0 state: down mac: N/A Device-4: dwmac-5.10a driver: N/A IF: end1 state: up speed: 1000 Mbps duplex: full mac: fe:fe:fe:c6:37:53 Device-5: dwmac-5.10a driver: N/A IF: can0 state: down mac: N/A Drives: Local Storage: total: 178.85 GiB used: 57.12 GiB (31.9%) ID-1: /dev/nvme0n1 model: 128GB SSD size: 119.24 GiB ID-2: /dev/sda model: KLUCG2U1DC-B0F1 size: 59.61 GiB Partition: ID-1: / size: 116.39 GiB used: 57.08 GiB (49.0%) fs: ext4 dev: /dev/nvme0n1p3 ID-2: /boot size: 223.7 MiB used: 44.4 MiB (19.9%) fs: ext4 dev: /dev/nvme0n1p2 Swap: Alert: No swap data was found. Sensors: System Temperatures: cpu: 413.8 C mobo: 395.6 C Fan Speeds (rpm): fan-1: 82 Info: Memory: total: N/A available: 31.38 GiB used: 1.02 GiB (3.3%) Processes: 305 Uptime: 2d 17h 12m Init: systemd Shell: Bash inxi: 3.3.40 |
What we have here is a 16-core SpacemiT X100 processor clocked at up to 2400 MHz, close enough to the 2.5 GHz advertised last year. It features 32 GB RAM, a 128 GB NVMe SSD, and a 64 GB UFS 2.2 flash device (KLUCG2U1DC-B0F1), and two Gigabit Ethernet ports. It runs recent software, namely Ubuntu 26.04 with Linux 6.12. Note that Ubuntu 25.10 and greater require an RVA23-compliant SoC, which the K3 provides. On the graphics side, the saturn-edp driver implies an embedded DisplayPort (eDP) display interface often used for display in laptops, and there’s no 3D hardware graphics acceleration (softpipe).
Something is clearly wrong with temperature reporting, but some other sensors return plausible temperatures:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
superkoning@spacemit:~$ sensors ctf2301-i2c-6-4c Adapter: spacemit-i2c-adapter fan1: 82 RPM temp1: +398.8°C temp2: +418.8°C pwm1: 100% (freq = 7826 Hz) thermal_6-virtual-0 Adapter: Virtual device temp1: +63.0°C thermal_4-virtual-0 Adapter: Virtual device temp1: +62.0°C thermal_2-virtual-0 Adapter: Virtual device temp1: +65.0°C thermal_0-virtual-0 Adapter: Virtual device temp1: +60.0°C thermal_7-virtual-0 Adapter: Virtual device temp1: +62.0°C thermal_5-virtual-0 Adapter: Virtual device temp1: +60.0°C thermal_3-virtual-0 Adapter: Virtual device temp1: +61.0°C thermal_1-virtual-0 Adapter: Virtual device temp1: +63.0°C |
Let’s add lspci output to see if we can find more devices:
superkoning@spacemit:~$ lspci 0000:00:00.0 PCI bridge: SpacemiT Device 0002 (rev 01) 0000:01:00.0 Non-Volatile memory controller: Silicon Motion, Inc. SM2263EN/SM2263XT (DRAM-less) NVMe SSD Controllers (rev 03) 0004:00:00.0 PCI bridge: SpacemiT Device 0002 (rev 01) |
Not much here.
Sander also ran sbc-bench.sh for us:
Note that those should be considered early benchmarks, as while 16 cores are detected, only eight cores were used when running 7-Zip or stress-ng, or when compiling a Linux kernel with “-j 30”.
With eight cores running, the SpacemiT K3 offers better performance than a Rockchip RK3588 SBC in 7-Zip. Here are charts showing a comparison between the K3, a Radxa Rock 5B (RK3588), a Raspberry Pi 5, and an Orion O6 mini-ITX motherboard (12-core CIX P1 Armv9 CPU).
The SpacemiT K3’s memory bandwidth looks to be on the low side and only a little better than a Raspberry Pi 5, while multi-core performance, as measured with 7-Zip, is slightly better than a Rockchip RK3588. aes-256-cbc performance (single-core) is quite low at 869,520.73k, as for instance, the Raspberry Pi 5 delivers 1,367,736.32k at the same CPU frequency. It looks specific to this workload, as single-core 7-Zip is 3136 MIPS for the Pi 5, and 2736 MIPS for the X100 core, still lower, but not quite as dramatic. You can find more details in the sbc-bench.log file. You’ll also find additional details on Sander’s GitHub repo, including the kernel log, coremark benchmark, and so on.
So far, the SpacemiT K3 delivers significant improvements over other RISC-V SoCs, but it does not offer amazing performance compared to existing Arm SoCs, being slightly better than a Rockchip RK3588 SoC. Pricing will determine whether it offers value, which has not been great for RISC-V platforms to date. One issue is the relatively low volumes of RISC-V SoCs, as South China Morning Post reports that the earlier SpacemiT K1 octa-core RISC-V SoC shipped over 150,000 units, which is not a whole lot. I’d expect the situation to improve over time, as RISC-V software becomes more mature, and mass production ramps up to higher volumes in the millions of units.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress. We also use affiliate links in articles to earn commissions if you make a purchase after clicking on those links.