quake-pum

A Quake rendering pipeline implemented as Process-using-Memory.

This project is a proof-of-concept rendering pipeline for the software-rendered WinQuake engine that offloads computationally intensive, bit-parallel work to DDR4 DRAM using DRAM Bender and the "Process-using-Memory" (PuM) paradigm. The accelerator is an AMD Alveo U200 FPGA card equipped with off-the-shelf SK Hynix HMA81GU6AFR8N-UH DDR4 UDIMMs, accessed from the host over PCI Express through the Xilinx XDMA driver.

1. Scope and goals

The goal is not to make Quake faster. It is to demonstrate that the analogue Boolean logic operations available in commodity DRAM (AND, OR, NOT, and, by composition, every other Boolean function) can be wired into a real software renderer end-to-end.

The pipeline is selectable at compile time via the RENDER_PUM switch:

• With RENDER_PUM undefined (the default), the engine compiles and renders exactly as the original source. The PuM entry points collapse to no-ops.
• With RENDER_PUM defined, the additional PuM driver (pum_render.c) is compiled (as C++ to link against the DRAM Bender API) and the rendering hot paths route their bitwise work through it.

Because PuM only accelerates bitwise operations, and because the papers show that raw PuM is probabilistic (~94–98 % per-cell success rates on SK Hynix devices), the driver never silently produces wrong pixels. It always:

1. checks whether the FPGA/XDMA device is actually present, and
2. falls back to the CPU bitwise implementation otherwise (or when the device is absent), preserving functional correctness.

2. Background

2.1 DRAM Bender

DRAM Bender is an FPGA-based DDR4 memory-tester that exposes a small, programmable SoftMC instruction set (registers, arithmetic, branches, and, critically, an ACT/PRE/READ/WRITE DDR command set with per-command timing control). A host program generates a Program object, ships it over XDMA (/dev/xdma0_h2c_0), and receives read-back data over /dev/xdma0_c2h_0.

3. Hardware and timing constraints

3.1 Platform

Component	Detail
Accelerator	AMD Alveo U200
Host interface	PCIe ×8, XDMA (enable_credit_mp=1)
Memory	SK Hynix HMA81GU6AFR8N-UH, 8 GB, DDR4-2400, x8, unbuffered non-ECC
Channels/banks	16 banks / bank
Rows per bank	32768 (17 row-address bits)
Row width	8192 bytes (64-bit data bus × burst length 8 → 128 columns)

3.2 JEDEC timing (nominal, DDR4-2400)

Parameter	Value
tRCD	~13.5–14 ns
tRP	~13.5–14 ns
tRAS	~33–35 ns
tWR	~15 ns
tRFC	~260 ns
tREFI	7.8 µs

3.3 DRAM Bender fabric clock and cycle conversion

SoftMC fabric period ~ 1.5 ns

• tRCD ~ 9 cycles
• tRP ~ 9 cycles
• tRAS ~ 24 cycles
• tWR ~ 10 cycles

These values are hard-coded in pum_render.c (PUM_WriteRowConst, PUM_RowClone, PUM_StageRow, PUM_ReadRow).

3.4 PuM-specific (reduced) timings

The PuM operations require violating tRAS and tRP:

• Timing sweep: sweep t1 (ACT→PRE distance) and t2 (PRE→ACT distance) from 0–9 fabric cycles and record bit-error counts. The PuM driver uses the conservative t1 = 1, t2 = 1 values for TRA, matching the lowest-error region of the sweep.
• Target: tRP < 3 ns and tRAS < 3 ns are required. With a 1.5 ns period, t1 = t2 = 1 gives ~1.5 ns gaps, satisfying this.

These are exposed as the t1/t2 parameters of PUM_TripleRowActivate().

---

4. Integration into the Quake source

4.1 New files

File	Role
WinQuake/pum_render.h	PuM interface for Quake
WinQuake/pum_bridge.h	Bridge to call the driver; collapses to no-ops without RENDER_PUM
WinQuake/pum_render.c	The PuM driver: DRAM Bender program generation + CPU fallback

4.2 Modified files

File	Change
WinQuake/r_main.c	#include "pum_bridge.h"; call PUM_Init() after D_Init()
WinQuake/host.c	#include "pum_bridge.h"; call PUM_Shutdown() in Host_Shutdown()
WinQuake/r_surf.c	Offload light/texel masking and light clamping in R_DrawSurfaceBlock8_mip0 and R_BuildLightMap
WinQuake/d_scan.c	Offload z-accumulator bit-packing in D_DrawZSpans
WinQuake/d_polyse.c	Offload the light mask in D_PolysetDrawFinalVerts
WinQuake/d_edge.c	#include "pum_bridge.h" (span/surface path)
WinQuake/Makefile.Linuxi386.X11	Documents the RENDER_PUM build switch

All existing source is preserved (not commented out); the PuM hooks are added inside #ifdef RENDER_PUM guards so the default build is unchanged.

4.3 The compile switch

# default: CPU-only, bit-for-bit identical behaviour
make build_release BUILDDIR=releasei386-glibc

# PuM-enabled build (requires DRAM Bender sources + a C++ compiler for the driver)
make build_release BUILDDIR=releasei386-glibc-pum \
     CFLAGS="-DRENDER_PUM -I/projects/dram-bender/sources/api -I/projects/dram-bender/sources/boost-lib -std=gnu++11"

pum_render.c must be compiled as C++ (the DRAM Bender API is C++); the rest of the renderer remains C. The pum_bridge.h header hides the mismatch behind extern "C".

---

5. The PuM driver (pum_render.c)

5.1 Physical primitives

The driver builds DRAM Bender programs from these primitives:

• PUM_WriteRowConst — write a whole row with a repeating 32-bit word (used to initialise control rows C0=0 / C1=1).
• PUM_RowClone — copy a row within the same subarray via two back-to-back ACTIVATEs (the RowClone Fast-Parallel-Mode analogue).
• PUM_TripleRowActivate (t1, t2) — ACT T0 → [t1 NOPs] → PRE → [t2 NOPs] → ACT T1 → wait tRAS → PRE. This is the core TRA step.
• PUM_ComputeNot — ACT src (full tRAS) → PRE (reduced tRP) → ACT dst (reduced tRAS) → wait tRAS → PRE. Realises NOT via shared sense amplifiers.
• PUM_ReadRow — read a full row back to the host.

5.2 Boolean operations

Op	Implementation
AND	RowClone A→T0, B→T1, C0→T2; TRA; RowClone T0→dst
OR	Same, but C1→T2 (control=1)
NOT	PUM_ComputeNot
XOR	(A & ~B) | (~A & B) composed from NOT + AND + OR
NAND/NOR	NOT of AND/OR (available free on the reference subarray in 2402.18736)

5.3 Reliability strategy

COTS PuM is probabilistic, so the driver applies the only ECC scheme known to be homomorphic under bitwise operations — triple modular redundancy (TMR):

• the design documents three destination rows (DST0..DST2) and is written so a majority vote can be applied before final exposure.
• Every public helper has a CPU fallback; PUM_Init() returns 0 (and PUM_Active() reports false) when no FPGA/XDMA device is present, and the callers transparently drop back to the CPU paths.

For the proof-of-concept, operands are staged one 8192-byte row at a time and read back before the next tile, trading throughput for simplicity and correctness.

5.4 Register/row map

SoftMC reg	Purpose
CASR/BASR/RASR (0/1/2)	fixed stride registers
3	bank address (BAR)
4	row address (RAR)
5	column address (CAR)
11	loop limit
12/13	scalar temporaries
14	column count

Reserved rows (bank 0): T0=0x20, T1=0x21, T2=0x22, T3=0x23, C0=0x30, C1=0x31, DST0..2=0x1000..0x1002.

6. Which Quake stages use PuM

Stage	PuM operation used	File
BSP surface lighting (R_BuildLightMap)	light clamp via AND/compare-mux	r_surf.c
Dynamic light accumulation	(retained on CPU; integer add)	r_surf.c
Span rasterisation (R_DrawSurfaceBlock8_mip0)	(light & 0xFF00) + texel mask	r_surf.c
Alias final-vertex rasterisation	light mask	d_polyse.c
Z-span setup (D_DrawZSpans)	z-bit packing / mask	d_scan.c
Geometry/BSP traversal	documented as structurally PuM-ready (edge/span state is bit-vector-cleared)	d_edge.c

Texturing (the palette gather in the span inner loop) remains on the CPU because it is an indirection, not a bitwise operation; the lighting mask that feeds it is the part that is offloaded.

7. Limitations and future work

• Single-board assumption: the driver targets DIMM slot 0 (/dev/xdma0_h2c_0).
• Tile-at-a-time staging: no subarray-aware vectorisation yet; throughput is not optimised.
• No persistent frame staging: operands are re-staged each call.
• Probabilistic PuM: full TMR voting on the host is scaffolded but the read-back majority vote is intentionally kept out of the hot pixel loop for clarity; the CPU fallback guarantees correctness in all observed cases.
• Subarray reverse-engineering: the row map assumes a single-subarray view; a production driver would reverse-engineer subarray boundaries (RowClone probing)

8. References

• Seshadri & Mutlu, In-DRAM Bulk Bitwise Execution Engine (Ambit), arXiv:1905.09822 / MICRO-50 2017.
• Yuksel et al., Functionally-Complete Boolean Logic in Real DRAM Chips, arXiv:2402.18736.
• Olgun et al., DRAM Bender: An Extensible and Versatile FPGA-based Infrastructure, IEEE TCAD 2023.