14:56:10 We can use XMRig (dev branch) now for testing: https://github.com/xmrig/xmrig/pull/3769 15:10:36 SpacemiT K3 RISC-V CPU: https://grokipedia.com/page/SpacemiT_K3 https://browser.geekbench.com/v6/cpu/16145076 15:10:44 16 cores, hardware AES support and 256-bit vectors 15:10:48 This one is interesting 15:52:24 Has anyone tested the Milk-V Mars? 15:52:37 It's not a super interesting board but I can post benchmarks 17:26:47 I keep getting a build error when trying to compile on the board. It seemed to work last time 17:27:08 Error finding "" 17:29:46 https://paste.debian.net/plainh/18041cbe 18:03:08 This is a standard header for risc-v gcc 18:03:19 double check that you're using a recent gcc version 18:39:18 Thanks. Looks like I'll have to compile it from source. 18:39:46 Looking back at older chat logs, it's gonna take a while haha 19:43:50 SpacemiT_K3 definitely sounds promising 19:44:53 no availability before April 19:45:49 Sipeed has a SpacemIT K1 module LicheePi 3A that can replace the LicheePi 4A CPU module 19:45:52 can get one of these with SG2044 https://en.sophgo.com/sophon-u/product/introduce/srb3-40.html :) 19:46:21 Would be cool if they release a new CPU module with the K3 19:46:37 https://www.cnx-software.com/2024/09/05/licheepi-3a-a-spacemit-k1-risc-v-development-board-with-som-and-carrier-board/ 19:48:18 still no sign of hardware AES in SG2044 21:26:09 It doesn't have hardware AES 21:26:52 Whatever they did in X9, it has to be either a separate accelerator on the same package (kind of like an APU), or a special version of SG2044 21:45:00 It has an on-die "Security Protocol Accelerator" that can do AES. Source: https://old.reddit.com/r/RISCV/comments/1lvm7j7/sophgo_technology_newsletter_20250709/ 21:47:40 ah nice find. have never seen their API 21:50:35 "Because encryption, decryption and hashing are performed entirely in the accelerator’s DMA pipeline, throughput is significantly higher" 21:50:38 "SPACC streams data over a 128-bit AXI interface" 21:50:47 So SG2044 is basically screwed with RandomX v2 21:51:09 This crypto accelerator is designed for throughput, not latency. And low latency is required in the main loop 21:52:20 the only hits I get on security protocol accelerator / spacc are from Synopsis 21:52:20 It's perfect for scratchpad fill/hash, but not so much for v2. 21:53:22 My tests on Orange Pi RV2 showed 2x slowdown with v2 because of software AES 21:53:44 and because of bigger program size, but software AES contributed the most 23:47:58 I googled a little about AXI interfaces - their typical latencies are 50-100 AXI clock cycles, and AXI clock frequency is in the range 100-250 MHz. 23:48:36 Best case scenario (250 MHz and 50 cycles) is 200 ns latency to get anything back from the SPACC 23:50:10 well, it has access to L3, so CPU cores can read processed data from L3 directly, but they still need to know when it's safe to read the data - they need to wait for SPACC's "ok" to read the data 23:58:47 nevermind, I was looking at the wrong numbers. It is much faster (5-10 cycles), and frequency can be as high as CPU cores 23:59:45 But SPACC can only exchange data with CPU cores through the L3 cache, as far as I understand, so the whole thing can't be faster than L3 access (+SPACC's internal latency)