Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V

Original Article ↗ Hacker News Discussion ↗

Running The Witcher 3 on a RISC‑V dev board via the Box64 x86_64 emulator prompts a broader look at how well RISC‑V’s current instruction set supports high‑performance workloads and game emulation. Commenters dissect missing or awkward instructions (like bitfield extract), compressed and variable‑length encodings, memory alignment guarantees, and vector extensions, weighing how these choices affect decoder complexity, code density, and performance relative to x86 and ARM. The thread also touches on Wine integration, GPU driver layers, and the extent to which the original “RISC simplicity” ideal still matters now that all major architectures rely on complex microarchitectures and toolchains.

Box64, Witcher 3, and Emulation Stack

  • Box64 is an x86_64 emulator that reuses native system libraries (libc, libm, SDL, OpenGL) for speed.
  • On RISC-V, it runs the x86_64 build of Wine; Wine itself still needs an emulator for x86 apps.
  • Some speculate about a hypothetical Wine build that exposes x86_64 APIs while compiling to RISC-V/ARM, but this is described as difficult and not what Box64 currently does.
  • Witcher 3 reportedly reaches ~15 fps via multiple translation layers (x86 → RISC-V CPU, DirectX → Vulkan via Wine/DXVK, then native GPU driver).

Hardware Used and Alternatives

  • The Witcher 3 demo uses Milk-V Pioneer, a RISC-V workstation board; it can ship with up to 128 GB RAM (clarifying confusion about the screenshot showing 31 GB).
  • Commenters note that newer RISC-V options with more/faster cores and RVV 1.0 support may now be better targets.

RISC-V ISA Design Debates

  • Strong criticism of missing bitfield extract/insert and limited addressing modes; some call this an obvious design gap.
  • Others note ongoing RISC-V working group discussions, vendor pressure, and clever instruction sequences that emulate bitfield operations reasonably efficiently.
  • Heated discussion around the compressed (C) extension:
    • Pros: higher code density, less I‑cache pressure, relatively simple length decode.
    • Cons: misaligned instructions spanning cache lines or pages, complexity in hardware and verification, large opcode space consumption.
    • Some argue C should be used mainly for microcontrollers; others say page-crossing cases are rare and manageable.
  • Misaligned load/store semantics and the lack of strong guarantees are seen as favoring hardware convenience over software needs.

RISC vs CISC and the “RISC dream”

  • Several participants argue modern high-performance cores (x86, ARM, RISC-V) have converged: all decode to micro-ops, use OoO, speculation, and large caches.
  • The original “RISC dream” of ultra-simple, one-cycle instructions with compilers doing all scheduling is widely viewed as largely obsolete; dynamic hardware scheduling and rich extensions dominate.
  • Others emphasize RISC-V’s main advantage as an open, license-free ISA and a simpler base to invest in, not minimality.

Practical Software Impact

  • For most software in higher-level languages, targeting RISC-V changes little.
  • With the compressed extension, RISC-V code size can be comparable to or smaller than x86-64 and ARM.
  • Key differences for low-level or runtime authors:
    • More general-purpose registers (32) reduce spills.
    • Important extensions (vector, bit-manipulation, conditional move) are not always guaranteed in base profiles, which affects optimization strategies.
  • Weaker memory model is similar to ARM; properly written concurrent code should not depend on x86’s stronger model.