E OF THE ART, JULY 2026 Researched 2026-07-31 from primary sources (RISC-V Tech Hub wiki, docs.riscv.org, arXiv, GitHub) for the Nishi sovereign library. Status key: RATIFIED / FROZEN / DRAFT / PLAN-ONLY / SHIPPING / ANNOUNCED / RESEARCH / PAYWALLED. Why this matters to Nishi: we built a sovereign SIMT GPGPU core (nx_simtcore). This document answers two questions -- what does the RISC-V standard give us, and what is the cheapest credible path to running REAL GPU kernels on it. === 1. THE SHARPEST FINDING: THERE IS STILL NO STANDARD RISC-V SIMT EXTENSION === ★★★THE RISC-V GRAPHICS AND MACHINE LEARNING SIG REPOSITORY WAS ARCHIVED ON 2026-04-23 and is read-only. Consequences, stated plainly: There is NO ratified RISC-V graphics extension. There are ZERO ratified texture or rasterisation proposals -- none, not even draft. There is NO standard divergence-control extension: no standard warp spawn, no standard reconvergence primitive. "RVG" is NOT a graphics extension -- it is legacy shorthand for the general-purpose combo IMAFD_Zicsr_Zifencei. So EVERY credible RISC-V GPU in 2026 still invents its own SIMT control instructions: Vortex (Georgia Tech): wspawn, tmc, split, join, bar, tex Ventus (Tsinghua): setrpc, vbranch, join -- layered ON TOP of RVV ★CONCLUSION FOR NISHI: our custom-0 (0x0B) and custom-1 (0x2B) encodings are THE NORM, not a shortcut. There is nothing to conform to, and no standard is coming from the group that owned it. === 2. VORTEX 3.0 -- THE BAR MOVED, 2026-06-09 === Released 9 June 2026. What it now contains: Fixed-function 3D stack: rasteriser, texture units, output mergers; public host-side graphics API with binning and triangle setup A HARDWARE RAY-TRACING UNIT TENSOR CORES with WGMMA (warpgroup-level MMA) and 2:4 STRUCTURED SPARSITY Vulkan via a new Mesa Gallium driver (vortexpipe); HIP via chipStar on rv32 and rv64 Hardware kernel scheduler, command processor, async barriers, DXA global-to-local transfer acceleration, MMU/SV32 Consumes RVC, Zicond (CZERO.EQZ / CZERO.NEZ), and the A extension Productised Synopsys and Yosys ASIC synthesis flows -- an actual tape-out path Baseline perf reference from MICRO'21 remains 32 cores on Stratix 10, 25.6 GFLOPS peak at 200 MHz. ⚠This is far beyond the 2021 paper most benchmarks (including ours) are calibrated against. === 3. RVV 1.0 -- ADEQUATE AS A DATAPATH, INADEQUATE AS A GPU CONTROL ISA === Ratified November 2021. ⛔THERE IS NO RVV 1.1 AND NO RVV 2.0, and this is an active misinformation trap: the ARCHIVED working-draft repo still says "Once ratified, the spec will be given version 2.0", which is STALE PRE-RATIFICATION TEXT. The repo was archived 2024-03-20; the spec shipped as 1.0. Search engines surface that line as if it were a live roadmap. No RVV 1.1/2.0 task group exists -- vector evolution happens entirely through discrete Zv* extensions. Measured criticisms, all RESEARCH: Strip-mining / power-of-two LMUL is a real cost. Zoozve (arXiv 2504.15678): removing strip-mining and allowing arbitrary register grouping gives >=10.10x dynamic instruction-count reduction on FFT for 5.2 percent area. ★PERMUTE IS NOT THE BOTTLENECK PEOPLE ASSUME. arXiv 2505.07112: single-cycle vector permutation up to VLEN=256 bits costs 1.5 percent of total vector-processor area at 7nm, trending toward 0 as minimum element width rises. This is counter-evidence to the "vrgather is an O(VLEN^2) crossbar disaster" claim at short VLEN. RVV 1.0 has NO block-scaled numerics. VMXDOTP (arXiv 2603.04979) adds MX support: up to 7.0x speedup vs software-emulated MXFP8 matmul, 4.9x energy efficiency, 7.2 percent area overhead. === 4. MATRIX EXTENSIONS: FOUR COMPETING, NONE RATIFIED === Confirmed 2026-07-31: no matrix extension appears in the ratified specification library. Zvldot / Zvbdot "no new state" dot-product fast-track; ratification PLANNED 2026-02-25 but NOT visible in the ratified library -- verify against the artifact before depending on it. Claim: 1000 MACs per instruction with FP8 in / FP32 out at VLEN=1024. IME Integrated Matrix Extension -- FROZEN v0.9, in public review since 2026-06-27, ratification target 2026-08-27. KEY CONSTRAINT: NO NEW ARCHITECTURAL STATE -- matrix data lives in the existing V registers. Types fp64, fp32, bf16, int8, fp8. VME Vector Matrix Extension (Zvopmm) -- DRAFT, plan approved 2026-07-16, ratification target 2026-11-18. Outer-product formulation into a LARGE MATRIX ACCUMULATOR: N^2 multiply-accumulates from N-element vector operands. AME Attached Matrix Extension -- earliest-stage DRAFT, ratification target 2027-04-29. SEPARATE architectural state: eight 2D matrix registers, four recommended as C accumulators. Viable STANDALONE with no vector unit present. The distinction that matters: IME = integrated, tiles are views onto the 32 V registers, so zero new context-switch cost, but tile size is hostage to VLEN. AME = attached, its own tile file, viable without a vector unit, but new state means new OS/ABI plumbing. VME sits between. ⚠⚠PICKING A TENSOR PATH MEANS BETTING BEFORE THE STANDARD SETTLES. This is the single largest architectural risk for anyone building a RISC-V GPU in 2026. === 5. RVA23 PROFILE -- AND THREE COMMON MISCONCEPTIONS CORRECTED === Ratified 2024-10-17. RVA23U64 makes V MANDATORY for the first time -- the precondition for a single shipped kernel binary. Ubuntu 25.10+ requires RVA23U64. Mandatory includes: RV64I + M A F D C B, Zicsr, Zicntr, Zihpm, Zfhmin, V, Zvfhmin, Zvbb, Zvkt, Zicond, Zimop, Zcmop, Zcb, Zfa, Zawrs, Supm. ⚠CORRECTIONS TO WIDELY-REPEATED CLAIMS: Zvfh is NOT mandatory -- it is an Expansion Option. Only Zvfhmin (widening/narrowing FP16 CONVERSIONS) is mandated. A GPU CANNOT ASSUME NATIVE FP16 VECTOR ARITHMETIC on an RVA23 part. Zacas is NOT mandatory -- it is a Development Option. Compare-and-swap cannot be assumed. EVERY BF16 EXTENSION IS OPTIONAL in RVA23 (Zfbfmin, Zvfbfmin, Zvfbfwma are all Expansion Options). Zvbb and Zicond ARE mandatory. Adoption reality: at RVA23's announcement Bruce Hoult noted "there are zero (0) RVA23 machines in the market at present" -- validated only on QEMU. The SpacemiT K3 (boards pre-order May 2026, 8x X100 up to 2.4 GHz, 60 TOPS INT4, 51 GB/s) is the first credible commercial RVA23 part -- an approximately 19-month gap between profile ratification and buyable silicon. ⛔RVA24 / RVA25 DO NOT EXIST. The riscv-profiles repository lists only RVA23/RVB23 and was itself ARCHIVED 2026-07-24. Where profiles work migrated to: UNKNOWN. === 6. THE COMPILER STACK: HOW A SOVEREIGN CORE RUNS REAL KERNELS === ⛔SoftCUDA (FCCM 2025, "Running CUDA on Softcore GPU") IS PAYWALLED -- a 5-page short paper with NO open-access copy (confirmed via Semantic Scholar, OpenAlex, DBLP, Unpaywall). DO NOT CITE ANY SOFTCUDA NUMBER. It is superseded by VOLT. VOLT (CC 2026, arXiv 2511.13751, repo vortexgpgpu/Volt, Apache-2.0, artifact zenodo.org/records/18071633) IS the reference. Architecture: PoCL front-end for OpenCL, extended CuPBoP front-end for CUDA, ALL SIMT analyses in stock LLVM IR, LLVM RISC-V back-end with an extended ISA table. Pins LLVM 18. No SYCL, no OpenMP. It extends the RISC-V TTI interface with isAlwaysUniform and isSourceOfDivergence -- i.e. it DRIVES LLVM's existing uniformity analysis rather than replacing it -- and reuses createStructurizeCFGPass() and stock -O2. ★★★THE COST NUMBER: Table 1 gives 1,565 LoC (OpenCL front-end) + 4,155 (CUDA front-end) + 4,653 (middle-end) = ABOUT 10,400 LINES OF NON-INTRUSIVE ADDITIONS for a full CUDA+OpenCL to SIMT-GPU toolchain. ⚠⚠BUT THAT ASSUMES A PRE-EXISTING LLVM BACKEND FOR THE BASE ISA. Writing a backend from scratch is strictly ADDITIVE and is UNMEASURED ANYWHERE IN THIS LITERATURE -- refuse any LoC estimate offered for it. Its nine middle-end passes are the transferable asset: uniformity analysis, divergence tracker, annotation analysis, function-argument analysis, CFG simplification, control-flow structurisation, CFG reconstruction, divergence-management function insertion, and ★A MACHINE-IR SAFETY-NET PASS AFTER REGISTER ALLOCATION -- they needed it because register allocation can break mask/IPDOM invariants. ★DESIGN IDIOM WORTH COPYING: their vx_split RETURNS THE IPDOM STACK ADDRESS, which is then the operand to vx_join. That makes join pairing EXPLICIT and survives code motion, instead of being implicitly stack-topped. Measured: the whole optimisation set costs 0.18 percent geomean compile-time slowdown; 32 OpenCL + 17 CUDA benchmarks all correct; SimX 4-core/16-warp/32-thread. HW vs SW WARP FEATURES (DATE 2025, arXiv 2505.03102) -- THE 2.42x vs 4x QUESTION, RESOLVED: The ABSTRACT says "up to 4 times geomean IPC speedup". Section V-A says "the HW solution achieving a 2.42x geomean speedup". ★THE ABSTRACT CONFLATES TWO STATISTICS. CITE 2.42x AS THE GEOMEAN; about 4x is the PER-KERNEL MAXIMUM (vote, shuffle, reduce, reduce_tile). ISA: vx_vote on CUSTOM0 (All, Any, Uni, Ballot); vx_shfl on CUSTOM1 (Up, Down, Bfly, Idx); vx_tile on CUSTOM2 (cooperative groups via variable group masks). Area overhead on Xilinx Alveo U50: total CLB overhead 1.08 percent (SLR 0) / 0.43 percent (SLR 1); about 2 percent total per core. ★ABOUT 1-2 PERCENT AREA FOR 2.42x GEOMEAN ON WARP-COLLECTIVE-HEAVY CODE -- building these in hardware is clearly right. ★★★THE FINDING NOT TO SKIP: on mse_forward the SOFTWARE PATH WINS, because loop serialisation REDUCES memory accesses that the hardware path re-issues per lane. HARDWARE WARP OPS ARE NOT UNIVERSALLY A WIN. Benchmark before assuming a shuffle unit always helps. SOFTWARE FALLBACK (COX, ACM TACO 2022, arXiv 2112.10034) -- how to emulate warp primitives without hardware: "Hierarchical collapsing": replace warp functions with runtime-library implementations; insert extra barriers derived from conditionals containing barriers; split basic blocks around each barrier; wrap in INTRA-warp loops (32 iterations) then INTER-warp loops (block_size/32). Mapping: block -> one pthread; warp -> outer loop; thread -> inner loop. Locals are SCALAR-EXPANDED to arrays. ★__shfl_sync lowers to a thread-local shfl_arr[32] -- and REQUIRES A RAW-HAZARD BARRIER BEFORE AND A WAR-HAZARD BARRIER AFTER. That is the non-obvious correctness requirement. Measured: 90 percent kernel coverage vs PoCL's 68 percent; 13 percent slowdown on kernels WITHOUT warp functions; 7.2x on 8 cores. ★USE THIS AS A DIFFERENTIAL CORRECTNESS ORACLE, not an execution path: compile the same CUDA kernel through CuPBoP to x86 and diff the answers against the sovereign core. Cheapest possible insurance for a new SIMT core. === 7. THE CUDA-PORTABILITY LANDSCAPE, JULY 2026 === chipStar SHIPPING (v1.3.0). Needs OpenCL 2.0/3.0 + SVM + SPIR-V input, or Level Zero. ⚠WARP SUPPORT IS PARTIAL: only NON-SYNC __all/__any/__ballot and __shfl_{up,down,xor}. __activemask() UNSUPPORTED. Cooperative Groups UNSUPPORTED. Warp Matrix UNSUPPORTED. Inline asm UNSUPPORTED. ZLUDA SHIPPING BUT DEFUNDED -- commercial funding ended; author states "back to being my weekend project". HIGH-RISK DEPENDENCY. SCALE SHIPPING, COMMERCIAL LICENCE. AMD + NVIDIA targets. Inline PTX asm supported. HIPIFY SHIPPING, source-to-source only, no runtime. rusticl SHIPPING, OpenCL 3.0 CONFORMANT. A SPIR-V CONSUMER -- useful as a reference implementation, not a path to a custom core. CuPBoP/COX RESEARCH, low activity. The live fork is VOLT's CuPBoP-Vortex. Nothing in this list is verifiably ABANDONED. === 8. THE RECOMMENDATION === For a team that has built its own SIMT core (warps, thread mask, IPDOM split/join, barriers, warp spawn, hardware shuffle/vote/ballot) with its OWN encodings, its own compiler and its own IR: ★IF THE BASE ISA IS RISC-V: adopt VOLT. Roughly 10.4K LoC of non-intrusive additions buys CUDA and OpenCL, with divergence handling already solved and validated on 49 benchmarks, plus the post-register-allocation safety net you would otherwise discover the hard way. If encodings differ, write a Vortex-ISA-to-our-encoding translator at the assembly or object level -- a bounded, testable job versus reimplementing a compiler. ★IF NOT RISC-V, OR IF KEEPING OUR OWN ENCODINGS: SPIR-V INGEST, NOT PTX. 1. OpenCL C -> clang -> SPIR-V. The LLVM SPIR-V backend is IN-TREE (spirv32/spirv64, SPIR-V 1.0-1.6, OpenCL and Vulkan environments). 2. Write a SPIR-V to our-IR consumer. Bounded work: a structured, versioned binary format with a reference parser. ★★THE DECISIVE ARGUMENT: OpenCL SPIR-V subgroup ops -- OpGroupNonUniformShuffle, OpGroupNonUniformBallot, OpGroupNonUniformAll/Any -- MAP 1:1 ONTO THE HARDWARE SHUFFLE/VOTE/BALLOT WE ALREADY BUILT. 3. Port VOLT's nine middle-end passes into our IR. We need their pass INVENTORY AND ORDERING, which is the hard-won part, not their code. ⛔DO NOT CHOOSE PTX. It is NVIDIA-proprietary and versioned per sm_XX -- a treadmill. ⚠DEFER writing a full LLVM backend until the ISA is stable and kernels demonstrably run. It is the highest ceiling and the highest cost, register allocation will fight the thread-mask/IPDOM invariants, and VOLT's measured 10.4K LoC explicitly EXCLUDES it. First light target: the HeCBench warp kernels VOLT used -- Vote, shuffle-cuda, Bscan, AtomicAgc, GC -- because they exercise exactly the primitives we built. license_tier: ORIGINAL -- Nishi-authored survey; no third-party text reproduced beyond short attributed quotations.