D READING THE FIGURES Recovered 2026-07-31 for the Nishi sovereign library. Source PDF: https://vortex.cc.gatech.edu/publications/vortex_micro21_final.pdf Paper: Tine, Elsabbagh, Yalamarthy, Kim -- Vortex: Extending the RISC-V ISA for GPGPU and 3D-Graphics, MICRO-54, 2021. arXiv 2110.10857 === WHY THIS DOCUMENT EXISTS === These figures are CHARTS. Their bar values, axis ranges and parameter legends live in the plot bitmap and vector art, NOT in the PDF text layer. Any text-extraction pipeline (pdfplumber, pdftotext, an LLM reading extracted text) reports them as UNKNOWN or, worse, misreads the axis labels. We rendered the pages with PyMuPDF at 9x and READ THEM VISUALLY. Everything below was previously unavailable to us. ★★★ RETRACTION OF AN EARLIER FINDING ★★★ A prior text-layer extraction reported that Figure 14 and Figure 19 have y-axes labelled CPI while their captions and legends say IPC, and we recorded that as an unresolved contradiction in the paper -- and used it to argue that Vortex publishes no usable absolute IPC. THE RENDERED FIGURES SHOW THE AXES ARE LABELLED IPC. The contradiction was an ARTIFACT OF TEXT EXTRACTION, not a defect in the paper. The claim is retracted. Absolute IPC IS published, in the figures, and is usable as a magnitude oracle. LAW: A FIGURE IS NOT TEXT. IF A NUMBER LIVES IN A CHART, ONLY LOOKING AT IT COUNTS AS READING IT. === FIGURE 14: IPC results for different core configurations === Single core. Y-axis IPC, 0 to 4.5, gridlines every 0.5. Five per-core configurations. Values read from the rendered chart (bar tops against gridlines): benchmark 4W-4T 2W-8T 8W-2T 4W-8T 8W-4T sgemm 2.00 2.40 1.47 4.30 2.90 vecadd 0.80 0.82 0.72 1.06 0.98 sfilter 1.50 1.60 1.20 1.63 1.56 saxpy 0.15 0.15 0.15 0.16 0.16 nearn 0.15 0.15 0.15 0.15 0.15 NOTE ON TOTAL THREADS: 4W-4T, 2W-8T and 8W-2T all have 16 threads -- these three are a fair comparison of how the SAME thread count is PARTITIONED. 4W-8T (32) and 8W-4T (32) have twice as many threads, so their higher IPC is not a like-for-like win. DERIVED RATIOS vs the 4W-4T baseline on sgemm (the quantities an independent implementation should reproduce): 2W-8T / 4W-4T = 2.40 / 2.00 = 1.200 8W-2T / 4W-4T = 1.47 / 2.00 = 0.735 ★ARITHMETIC FINDING ABOUT THE PAPER'S OWN PROSE: the text says the 8W-2T change brings "a reduction in performance in terms of IPC, 36% for sgemm in the extreme case." The figure shows 2.00 -> 1.47, which is a 26.5% REDUCTION. But 2.00 / 1.47 = 1.36. The paper's "36%" is the RATIO expressed as a percentage, not a percentage reduction. Quote the ratio 0.735, or say "1.36x slower" -- do not repeat "36% reduction" as if it were a decrement. The "+20%" figure for 2W-8T is unambiguous because 2.40/2.00 = 1.20 reads the same either way. === FIGURE 15: Area distribution (single core, 8-core system) === Pie chart, previously UNKNOWN because it is a raster image. Slices sum to exactly 100%: Dcache 35% TEX 20% <- the texture unit is the SECOND largest block on the core FPU 13% Other 9% ALU 7% Icache 6% Ibuffer 6% Smem 3% GPR 1% <- the register file is almost free; the memory system is not Context from the text: at eight cores, 53% of the Arria 10 logic is used, dominated by texture units and caches (16KB L1 + shared memory). FPU area is low because the design uses the FPGA's existing floating-point DSP blocks for FMA. DESIGN CONSEQUENCE: 41% of the core is cache (Dcache 35 + Icache 6). Adding a texture unit costs about 20%. Registers are noise. If you are budgeting a sovereign GPU core, the memory system IS the chip. === FIGURE 18: Vortex performance scaling (core count) === Previously COMPLETELY UNKNOWN -- an embedded raster image with no text layer at all. Dual axis. LEFT axis "IPC-compute bounded" 0 to 40 serves vecadd, sgemm, sfilter. RIGHT axis "IPC-memory bounded" 0 to 2.5 serves saxpy, nearn, guassian [sic], bfs. COMPUTE-BOUNDED (left axis, IPC): benchmark 1-core 2-core 4-core 8-core 16-core 32-core vecadd 2.1 3.8 6.9 10.5 15.5 19.1 sgemm 1.9 3.8 7.8 15.3 27.1 32.5 sfilter 1.4 4.8 9.2 15.7 25.8 32.5 MEMORY-BOUNDED (right axis, IPC; read against the 0-2.5 scale): saxpy 0.15 0.16 0.20 0.24 0.36 0.54 nearn 0.14 0.14 0.15 0.15 0.15 0.15 <- essentially FLAT guassian 0.13 0.21 0.40 0.74 1.00 1.20 bfs 0.01 0.03 0.06 0.12 0.21 0.29 SCALING EFFICIENCY 1 -> 32 cores (derived): sgemm 1.9 -> 32.5 = 17.1x on 32 cores = 53% of linear sfilter 1.4 -> 32.5 = 23.2x = 73% of linear vecadd 2.1 -> 19.1 = 9.1x = 28% of linear These are the multi-core oracle targets for any independent implementation that adds clustering. The text's claim that nearn is the exception is confirmed by the figure: nearn is flat across all six core counts, because it is compute-bound on a long-latency floating-point square root. ★CROSS-VALIDATION AND ONE DISCREPANCY: Figure 18's 1-core values should match Figure 14's 4W-4T column (the baseline config). They agree for sgemm (1.9 vs 2.00), sfilter (1.4 vs 1.50), saxpy (0.15 vs 0.15) and nearn (0.14 vs 0.15). They DISAGREE for vecadd: Figure 18 shows about 2.1 at one core while Figure 14 shows 0.80. That is a 2.6x mismatch between two figures in the same paper for the same benchmark and configuration. Cause UNKNOWN -- possibly a different input size or a plotting error. Do not treat vecadd's Figure 18 curve as comparable to its Figure 14 bar. === FIGURE 19: The effect of multi-port caches === Single core, 4W-4T, varying virtual ports on the data cache bank. Left axis IPC 0-9, right axis Bank Utilization 0-100%. sgemm: 1-port IPC 7.2, 2-port 7.8, 4-port 8.3 vecadd, sfilter: about 1.65 flat across all port counts saxpy, nearn: about 0.15 flat Bank utilization: 1-port sgemm 67%, vecadd 71% (matches the prose); rises toward 100% as ports increase; 4-port line sits at 100%. ★METRIC INCONSISTENCY BETWEEN FIGURES: Figure 19 shows sgemm at 7.2 IPC on a single core while Figure 14 shows the same benchmark and configuration at 2.00 IPC. 7.2 is close to 2.00 x 4 threads = 8.0, so Figure 19 appears to plot LANE-instructions per cycle while Figure 14 plots WARP-instructions per cycle. The paper does not state this. If you compare across these two figures without noticing, you will be wrong by roughly the thread count. === FIGURE 20: HW texture acceleration vs software === Execution time in ms, lower is better. SW vs HW, three filter modes, at 1/2/4/8 cores. cores mode SW HW speedup 1 Point 128 127 1.01x 1 Bilinear 508 265 1.92x <- the prose's "almost 2x on a single core" 1 Trilinear 560 468 1.20x 2 Point 93 95 0.98x 2 Bilinear 297 175 1.70x 2 Trilinear 332 258 1.29x 4 Point 85 83 1.02x 4 Bilinear 222 118 1.88x 4 Trilinear 265 212 1.25x 8 Point 44 47 0.94x 8 Bilinear 128 66 1.94x 8 Trilinear 218 178 1.22x Point sampling shows NO benefit (and is sometimes marginally slower) because the source texture is already RGBA, so the software path degenerates to a copy. Trilinear gains less than bilinear because it doubles memory requests. === FIGURE 21: The effect of memory scaling on performance === Previously COMPLETELY UNKNOWN. THE MOST VALUABLE RECOVERY IN THIS DOCUMENT, because its legend defines the memory parameter space: sh: 24-cycle memory latency lg: 200-cycle memory latency 2c: 2-channel memory 8c: 8-channel memory l2: L2 cache enabled Configuration per the text: 16-core, 16-wavefront, 16-thread, via the SIMX cycle-level simulator. Left axis IPC-compute bounded 0-120; right axis IPC-memory bounded 0-2.5. benchmark sh+2c lg+2c lg+2c+l2 lg+8c lg+8c+l2 vecadd 19.5 4.5 4.8 17.0 17.0 sgemm 103.0 16.5 18.5 39.5 39.5 sfilter 4.5 1.5 1.8 3.2 3.0 (right axis, memory-bounded) saxpy 1.06 0.32 0.34 0.41 0.43 nearn 0.26 0.15 0.15 0.15 0.15 ★THE HEADLINE NUMBER: sgemm runs at 103 IPC with 24-cycle memory and 16.5 IPC with 200-cycle memory -- a 6.2x swing from MEMORY LATENCY ALONE, at identical compute configuration. Going from 2 channels to 8 channels at long latency recovers 16.5 -> 39.5, a 2.4x bandwidth win. Enabling L2 does almost nothing by comparison (16.5 -> 18.5 at 2c; no change at 8c). DESIGN CONSEQUENCE: for this class of core, memory LATENCY dominates, memory BANDWIDTH is second, and an L2 is nearly irrelevant. Anyone budgeting effort on a sovereign GPU should spend it on latency hiding (more warps in flight) and channels before building an L2. === HOW NISHI USED THIS === These recovered numbers upgraded the sovereign SIMT core benchmark (nx_simtcore_gate) from DIRECTION-only agreement to MAGNITUDE agreement: - The 24-cycle / 200-cycle pair replaced an INVENTED 20-cycle latency constant in nx_simtcore.nx. The invented value silently modelled the optimistic end of Vortex's own range. - The 2-channel / 8-channel pair drove a new channel-arbitration model, replacing a latency-only memory model in which the channel count was inert. - Figure 14's ratios 1.200 and 0.735 became the magnitude targets. Our sgemm-like multiply-accumulate kernel at the cache-resident corner measures 1.150 and 0.775 -- within 50 and 40 per-mille of Vortex. - A HYPOTHESIS WAS REFUTED BY THIS DATA AND IS RECORDED AS SUCH: we predicted the LONG-latency corner would match Vortex's Figure 14 ratios better. It does not; long latency damps every ratio toward 1.0 and lands 449 per-mille away versus 90 for the short-latency corner. Figure 14 was measured on real FPGA silicon with its caches working, so the cache-resident corner is the correct comparison point; Figure 21's 200-cycle setting is a what-if sweep, not the Figure 14 baseline. license_tier: ORIGINAL. This document is Nishi-authored analysis and transcription of measurements from a published paper, used as a benchmark oracle. No Vortex code, RTL or asset is copied into the Nishi ecosystem.