STREAMINGGS: Voxel-Based Streaming 3D Gaussian Splatting with Memory Optimization and Architectural Support

Chenqi Zhang; Chentao Wu; Guangda Liu; Jieru Zhao; Minyi Guo; Wenchao Ding; Yu Feng

REVIEW 4 major objections 5 minor 29 references

STREAMINGGS: Voxel-Based Streaming 3D Gaussian Splatting with Memory Optimization and Architectural Support

T0 review · 4 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A voxel-based, memory-centric redesign of 3D Gaussian Splatting rendering claims to make 90 FPS achievable on mobile hardware by eliminating intermediate off-chip traffic.

desk verdict Real algorithmic step for 3DGS memory efficiency, but the headline speedup and energy numbers rest on an undescribed simulator, so treat them as unverified. read the letter →

arxiv 2506.09070 v1 pith:46KSYEUF submitted 2025-06-09 cs.GR cs.AI

Chenqi Zhang , Yu Feng , Jieru Zhao , Guangda Liu , Wenchao Ding , Chentao Wu , Minyi Guo This is my paper

classification cs.GRcs.AI

keywords 3DGaussiansplattingmemory-centricrenderingvoxel-basedstreamingDRAMtrafficreductionhierarchicalfilteringvectorquantizationmobileGPUacceleratorreal-time

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper sets out to establish that the bottleneck of 3D Gaussian Splatting on mobile devices is not computation but the DRAM traffic caused by tile-centric rendering. It replaces that paradigm with a memory-centric one: the scene is partitioned into voxels, each voxel is streamed onto the chip once, and projection, sorting, and rendering happen on-chip before only final pixel values return to DRAM. To keep the voxel stream lean, the method uses two-phase hierarchical filtering plus vector-quantized feature compression, and a boundary-aware fine-tuning step keeps rendering order correct across voxel boundaries. If the reported numbers hold, real-time 90 FPS 3DGS rendering is within reach on mobile-class hardware with essentially no quality loss.

What carries the argument

The central mechanism is the voxel-based memory-centric rendering pipeline, which has four named parts. The voxel sorting unit partitions the scene into voxels and uses a topological sort to build a global rendering order for all voxels intersected by a pixel group. The hierarchical filtering unit is a two-phase Gaussian culling scheme: a coarse phase reads only the lightweight half of each Gaussian's parameters, and a fine phase uses the compressed second half for precise intersection tests. Vector quantization compresses that second half into codebook indices stored off-chip while the codebook itself stays on-chip. Boundary-aware fine-tuning adds a cross-boundary penalty loss $\mathcal{L}_{CBP}$ that shrinks Gaussians spanning voxel boundaries, so voxel-order rendering matches true depth order; together these parts regularize DRAM access and eliminate intermediate off-chip traffic.

What would settle it

Run the STREAMINGGS accelerator model in a cycle-accurate simulator that models LPDDR3 DRAM timing, bank conflicts, refresh, and the overlap between voxel streaming and rendering, and measure end-to-end energy for the four benchmark scenes; if the speedup over a mobile Ampere GPU falls substantially below the reported 45.7×, the central bandwidth-bound claim would be falsified.

Watch

Extended reading notes

Core claim

The paper's central claim is that the entire 3DGS rendering pipeline can be made fully streaming by switching from a tile-centric to a memory-centric computation pattern. Partitioning the scene into voxels and rendering voxel-by-voxel makes each stage's intermediate data small enough to stay on-chip, so the intermediate off-chip traffic that dominates the original pipeline is eliminated. A voxel sorting unit establishes global voxel order via topological sort; hierarchical filtering first rejects Gaussians using only 4 parameters (coordinates plus maximum scale), then uses vector-quantized codebook indices for precise intersection testing; and boundary-aware fine-tuning reshapes cross-boundary Gaussians to preserve depth order. The claimed result is 45.7× speedup and 62.9× energy reduction over a mobile Ampere GPU, with average PSNR dropping only 0.04 dB across three 3DGS algorithms and four datasets.

Load-bearing premise

The central quantitative claim stands on the performance and energy simulator used to produce the 45.7× speedup and 62.9× energy numbers; the paper specifies the synthesis process and DRAM model but does not describe or validate that simulator.

Editorial extensions

If this is right

A 90 FPS real-time target becomes plausible on mobile-class GPUs: the design reports 45.7× speedup over a mobile Ampere GPU while keeping average quality loss at 0.04 dB PSNR.
Hierarchical filtering is the main performance lever: removing coarse-grained filtering drops the speedup from 45.7× to 22.2×, while vector quantization has a smaller performance impact because voxel streaming overlaps later stages.
DRAM traffic is cut at two points: vector quantization removes 92.3% of voxel-streaming traffic, and hierarchical filtering reduces the number of Gaussians processed per voxel by 76.3%.
The streaming pipeline composes with existing 3DGS compression and pruning algorithms: quality is preserved on 3DGS, Mini-Splatting, and LightGaussian, so memory-centric streaming can be added on top of different base representations.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The same voxel-streaming idea could be applied to 3DGS training, where off-chip traffic is also a known bottleneck, though the paper only evaluates inference; that extension would need to handle gradient accumulation across voxels.
If the bandwidth-bound thesis carries out, memory-centric restructuring should also benefit other tile-based neural renderers, such as radiance-field pipelines that do not use Gaussian splats.
The codebook-plus-indices layout suggests a path toward rendering directly from a compressed scene representation without ever expanding the model on device; testing this on a wider range of scenes would show whether the 0.04 dB average quality drop remains bounded.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

First thing to know: this is a real algorithmic contribution with a shaky quantitative wrapper. The idea of partitioning 3DGS into voxels and streaming voxel-by-voxel through a custom pipeline is new relative to GSCore's tile-centric design, and the hierarchical two-phase filter with codebook indices is a clever way to cut DRAM traffic. The rendering-quality evaluation is honest: they test on four datasets and three base algorithms, and the average PSNR drop is 0.04 dB. That part I believe. The boundary-aware fine-tuning that fixes cross-voxel ordering is specific and looks plausible, and the Fig. 7 curves are consistent with the story.

The problem is the 45.7x speedup and 62.9x energy savings. The paper never describes the performance simulator that produced those numbers. We get synthesis at TSMC 32nm, CACTI 7.0 for SRAM, and a Micron LPDDR3 datasheet for DRAM, but no cycle-accurate model, no DRAM contention model, no queue occupancy or VSU/HFU stall modeling. The one sentence saying they 'validate our results against reported data' for GSCore doesn't show the validation. The GPU baseline is 'built-in hardware measurements' without a measurement protocol. So the central quantitative claims are currently not reproducible from the manuscript. On top of that, comparing a 7nm-class mobile GPU measured in hardware to a 32nm synthesized accelerator without normalizing technology is apples-to-oranges; the energy gap could easily be off by a factor from process alone.

There are minor issues too: the abstract says 'up to 45.7x' but the body reports it as the average; they cite their own prior streaming works but don't compare against Potamoi or Cicero, which are closest in spirit. Those are not fatal, but they add friction.

Where does that leave us? The algorithmic architecture is worth serious attention. The DRAM-traffic reduction argument is qualitatively sound even if the exact factor is unverified. If a simulator description and validation were added, or even a carefully-scoped analytical model with sensitivity analysis, this could be a strong paper. As it stands, I would not quote the 45.7x/62.9x numbers in my own work, but I would cite the method and I would want to see the missing simulator in a revision.

Give it a serious referee, yes. It's a DAC paper with a real idea, and the right reviewers will ask the right questions. Bring it to reading group maybe, mostly to discuss how much simulation transparency an architecture paper owes when the algorithm side is solid but the hardware numbers are opaque.

Referee Report

4 major / 5 minor

Summary. The paper presents STREAMINGGS, an algorithm-architecture co-design for streaming 3D Gaussian splatting (3DGS) on mobile devices. The algorithm partitions the scene into voxels, renders in a memory-centric order, applies hierarchical filtering (coarse then fine) with vector-quantized codebooks, and uses boundary-aware fine-tuning to reduce cross-boundary ordering errors. The architecture adds a voxel sorting unit (VSU) and hierarchical filtering unit (HFU) to a GSCore-like sorting/rendering pipeline. The authors report average PSNR losses of about 0.04 dB across four datasets and three 3DGS variants, and claim a 45.7x speedup and 62.9x energy reduction over the Orin NX GPU, as well as 2.1x/2.3x gains over GSCore. The rendering-quality results are evaluated with clear protocols, but the performance and energy figures depend on a simulation setup that is described only by listing synthesis tools, CACTI, and a DRAM model, without specifying the simulator itself.

Significance. If the quantitative results are reproducible, the memory-centric streaming paradigm is a substantial advance for mobile 3DGS: eliminating intermediate off-chip traffic and regularizing DRAM accesses while preserving rendering quality is exactly what is needed for real-time mobile VR/AR. The paper's quality evaluation is credible: Table II spans standard datasets and multiple baselines, the fine-tuning curve in Fig. 7 supports the claimed regression, and the architectural components (VSU, HFU, VQ codebook) are clearly presented. However, the headline claims of speedup and energy savings are not verifiable from the manuscript alone because the performance simulator and the GPU measurement protocol are not disclosed. The paper would materially benefit from releasing the simulator source or a detailed validation study.

major comments (4)

[Sec. V-A, Sec. V-C, Fig. 11] The 45.7x speedup and 62.9x energy savings are simulation outputs, but the simulation framework is never described. The manuscript only names the synthesis library (TSMC 32nm), CACTI 7.0, and an LPDDR3 datasheet; it does not describe the cycle-accurate model, the DRAM latency/contention model, the queue/occupancy model for VSU, HFU, sorting, and rendering, or the validation of the GSCore implementation. The single sentence 'We implement GSCore based on its published specifications and validate our results against reported data' cannot substantiate the baseline numbers. Please provide the simulator architecture, a validation comparison against GSCore's published results and against measured Orin NX traces, and a cycle/energy breakdown across pipeline stages.
[Sec. V-A, Sec. V-C] The GPU baseline is said to be recorded with 'built-in hardware measurements,' but no protocol is given: no frame count, warm-up, GPU clock configuration, power measurement domain (GPU-only vs. SoC), or frame synchronization. The accelerator is synthesized at 32nm while the Orin NX is a modern mobile GPU; comparing energy across different technology nodes without scaling or calibration makes the 62.9x energy-reduction figure difficult to interpret. Report the exact measurement protocol and either scale the accelerator to a comparable technology node or bound the process-technology effect on the energy comparison.
[Sec. IV-B, Sec. V-C] The claim that VQ has 'minimal impact on performance' because voxel streaming is 'overlapped by the subsequent stages' presumes an ideal streaming overlap that is not demonstrated. The paper does not report whether the on-chip intermediate buffer (89 KB) and codebook buffer (250 KB) are sufficient for the largest voxel encountered in the tested scenes, nor whether DRAM contention between input voxel streaming, codebook fetches, and parameter fetches is modeled in the simulator. Please provide voxel-size distributions, buffer-occupancy traces, and a description of how streaming overlap and DRAM contention are accounted for; without this, the 'fully streaming' claim and the speedup figures remain unsupported.
[Sec. III-B, Eq. (2)] The loss L_CBP penalizes every Gaussian whose depth is smaller than the maximum depth among previously processed Gaussians, rather than specifically penalizing Gaussians that cross voxel boundaries. The text states that this loss 'punishes the cross-boundary Gaussians,' but the equation as written targets all depth-order violations in the voxel-based rendering order. To establish the stated mechanism, please provide an ablation with and without L_CBP, or a distribution showing which Gaussians receive T_i=1, since the current definition may also distort non-boundary Gaussians and the claimed causal effect on cross-boundary errors is not demonstrated.

minor comments (5)

[Fig. 2, Sec. II-B] The percentage labels in Fig. 2 (25.9%, 23.9%, 8.0%, etc.) are not clearly mapped to the pipeline stages, and the text's 41% and 49% figures for projection and sorting do not obviously reconcile with the figure; please clarify the traffic breakdown.
[Abstract vs. Sec. V-C] The abstract states 'up to 45.7x speedup' while Sec. V-C reports an average of 45.7x; please align the wording.
[Sec. III-C] The claim of reducing DRAM traffic by 92.3% needs an explicit baseline: is it relative to the uncompressed second half, to the full voxel streaming traffic, or to the original tile-centric 3DGS pipeline?
[Footnote 1] The footnote announcing acceptance at DAC 2025 is unusual for a journal submission; it should be removed or replaced with a proper provenance or extended-version statement.
[Sec. V-A] Please specify the exact Synopsys/Cadence synthesis flow and the CACTI configuration (cache/buffer geometry, number of ports, technology assumptions) so that the area and energy numbers in Table I and Fig. 11 are reproducible.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation found: STREAMINGGS's speedup and energy claims are simulation outputs with an undisclosed simulator, which is a reproducibility risk, not circularity.

full rationale

Walking the paper's derivation chain, the memory-centric rendering transform is an algorithmic proposal, not a quantity fitted to the target result. Sections III-B and III-C define voxel ordering, boundary-aware fine-tuning, and hierarchical filtering; none of these equations reduce to the 45.7x or 62.9x figures. The evaluation in Section V reports simulation results from a synthesis flow and DRAM models; the missing cycle-accurate simulator description is a validation gap, but no equation in the paper defines the speedup in terms of the simulator's assumptions. Hyperparameters such as voxel size, beta, and codebook sizes are chosen empirically and tested in sensitivity studies; the headline result is not a prediction of a fitted parameter. The self-citations [19] and [21] (Potamoi and Cicero) appear as contextual references for streaming and neural-rendering memory optimizations, and the sorting and rendering units are adopted from GSCore [18], an external paper; no load-bearing claim reduces to a self-citation. The quality comparison in Table II is against external 3DGS implementations with no fitted quality target. Thus no specific reduction of output to input can be exhibited, so the circularity score is 0. The undisclosed performance simulator and missing GPU measurement protocol are correctness and reproducibility concerns, not circularity.

Assumptions & free parameters 6 free parameters · 5 assumptions · 0 invented entities

The design introduces several hand-tuned knobs and relies on unproven hardware-modeling assumptions. The most consequential are the voxel size and beta in the loss, and the assumption that on-chip buffers can always hold a voxel's intermediate data.

free parameters (6)

voxel_size_real_world = 2
Chosen from sensitivity analysis (Fig. 12) as a trade-off between quality and energy; larger voxels increase filtering work, smaller voxels increase cross-boundary errors.
voxel_size_synthetic = 0.4
Set in Sec. V-A; no sensitivity analysis shown for synthetic scenes.
beta = 0.05
Hyper-parameter balancing the cross-boundary penalty in Eq. (1). Hand-set.
codebook_entries_scale_rotation_dc = 4096
Codebook size for vector quantization of scale, rotation, and DC, set in Sec. V-A.
codebook_entries_sh = 512
Codebook size for SH coefficients, set in Sec. V-A.
cfu_ffu_count = 4 CFUs, 1 FFU
Hardware configuration selected from Fig. 13 sensitivity study.

assumptions (5)

domain assumption 3DGS alpha-blending model is the correct rendering model
The paper assumes the standard 3DGS pipeline (projection, sorting, blending) and only changes the traversal order, not the blending model.
ad hoc to paper Voxel intermediate data always fits on-chip
The paper claims 'guarantees' no off-chip intermediate traffic but gives no worst-case bound on the number of Gaussians per voxel or on the per-ray accumulator size. A dense voxel could overflow the 355 KB on-chip storage.
ad hoc to paper The unspecified performance simulator faithfully models the accelerator
No simulation framework is described in Sec. V-A; the speedup and energy claims are only as trustworthy as this unnamed model.
domain assumption LPDDR3 DRAM model and Micron power calculator match the mobile target
The paper uses an LPDDR3 model and power calculator for energy; the Orin NX GPU uses a different memory system, so the comparison baseline is not fully matched.
domain assumption Topological sort DAG from per-pixel voxel orders is acyclic
The paper asserts no cycles (Sec. III-B) without proof; for disjoint voxels with a common camera this is plausible but not demonstrated.

how reviews work

0 comments

Cite this review

Pith. "Pith review of STREAMINGGS: Voxel-Based Streaming 3D Gaussian Splatting with Memory Optimization and Architectural Support." pith.science (2026). https://pith.science/paper/46KSYEUF

@misc{pith2026250609070,
  author       = {Pith},
  title        = {Pith review of: STREAMINGGS: Voxel-Based Streaming 3D Gaussian Splatting with Memory Optimization and Architectural Support},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/46KSYEUF}},
  note         = {Machine review of arXiv:2506.09070}
}

abstract

3D Gaussian Splatting (3DGS) has gained popularity for its efficiency and sparse Gaussian-based representation. However, 3DGS struggles to meet the real-time requirement of 90 frames per second (FPS) on resource-constrained mobile devices, achieving only 2 to 9 FPS.Existing accelerators focus on compute efficiency but overlook memory efficiency, leading to redundant DRAM traffic. We introduce STREAMINGGS, a fully streaming 3DGS algorithm-architecture co-design that achieves fine-grained pipelining and reduces DRAM traffic by transforming from a tile-centric rendering to a memory-centric rendering. Results show that our design achieves up to 45.7 $\times$ speedup and 62.9 $\times$ energy savings over mobile Ampere GPUs.

Figures

Figures reproduced from arXiv: 2506.09070 by the authors.

**Figure 3.** FPS of different scenes on a mobile SoC, Orin NX. 3DGS cannot achieve real-time on both synthetic and real-world scenes. Lego PalaceTrain Playroom Truck Drjohnson 0 50 100 150 200 250 DRAM Throughput (GB/s) Projection Sorting Rendering 102.4 Synthetic Real World Orin NX Bandwidth [PITH_FULL_IMAGE:figures/full_fig_p002_3.png] view at source ↗

**Figure 5.** The overview of our fully-streaming algorithm. Our algorithm initially partitions the entire 3D scene into small voxels. For each image tile, we first [PITH_FULL_IMAGE:figures/full_fig_p003_5.png] view at source ↗

Figures from the paper (6 more)

**Figure 6.** Figure 6: An example of incorrect rendering order among Gaussians and the effect of boundary-aware fine-tuning. 0 1000 2000 3000 0.0 0.5 1.0 1.5 2.0 2.5 21.2 21.6 22.0 22.4 22.8 PSNR (dB) Error Gaussian Ratio (%) PSNR (dB) Error Gaussian Ratio (%) Fine-Tuning Iterations [PITH_…

**Figure 8.** Figure 8: The DRAM Data layout. We separate the Gaussian features into two [PITH_FULL_IMAGE:figures/full_fig_p004_8.png]

**Figure 9.** Figure 9: Overview of STREAMINGGS accelerator, consisting of four components: a voxel sorting unit (VSU), a hierarchical filtering unit (HFU), a sorting unit, and a rendering unit. Our contributions are highlighted in colors: HFU is in yellow and VSU is in purple. The detailed …

**Figure 10.** Figure 10: The design of voxel sorting unit (VSU). It first identifies the [PITH_FULL_IMAGE:figures/full_fig_p005_10.png]

**Figure 11.** Figure 11: End-to-end speedup and energy savings of our variants over the GPU [PITH_FULL_IMAGE:figures/full_fig_p006_11.png]

**Figure 12.** Figure 12: The sensitivity of energy efficiency and rendering quality on the original 3DGS to voxel size. We only evaluate on train scene. 1 2 3 4 FFU 1 2 3 4 CFU 20.6 20.6 20.6 20.6 31.9 32.2 32.2 32.2 39.7 40.2 40.3 40.3 45.6 46.4 46.7 46.8 25 30 35 40 45 Speedup [PITH_FULL_I…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

29 extracted references · 17 canonical work pages

[1]

Pharr, W

M. Pharr, W. Jakob, and G. Humphreys,Physically based rendering: From theory to implementation. MIT Press, 2023

2023
[2]

Toward real-time ray tracing: A survey on hardware acceleration and microarchitecture techniques,

Y . Deng, Y . Ni, Z. Li, S. Mu, and W. Zhang, “Toward real-time ray tracing: A survey on hardware acceleration and microarchitecture techniques,”ACM Computing Surveys (CSUR), vol. 50, no. 4, pp. 1–41, 2017

work page 2017
[3]

Nerf: Representing scenes as neural radiance fields for view synthesis,

B. Mildenhall, P. P. Srinivasan, M. Tancik, J. T. Barron, R. Ramamoorthi, and R. Ng, “Nerf: Representing scenes as neural radiance fields for view synthesis,”Communications of the ACM, vol. 65, no. 1, pp. 99–106, 2021

2021
[4]

Mip-nerf: A multiscale representation for anti- aliasing neural radiance fields,

J. T. Barron, B. Mildenhall, M. Tancik, P. Hedman, R. Martin-Brualla, and P. P. Srinivasan, “Mip-nerf: A multiscale representation for anti- aliasing neural radiance fields,” inProceedings of the IEEE/CVF Inter- national Conference on Computer Vision, pp. 5855–5864, 2021

work page 2021
[5]

Recent advances in 3d gaussian splatting,

T. Wu, Y .-J. Yuan, L.-X. Zhang, J. Yang, Y .-P. Cao, L.-Q. Yan, and L. Gao, “Recent advances in 3d gaussian splatting,”arXiv preprint arXiv:2403.11134, 2024

arXiv 2024
[6]

A survey on 3d gaussian splatting,

G. Chen and W. Wang, “A survey on 3d gaussian splatting,”arXiv preprint arXiv:2401.03890, 2024

arXiv 2024
[7]

3d gaussian splatting for real-time radiance field rendering,

B. Kerbl, G. Kopanas, T. Leimk ¨uhler, and G. Drettakis, “3d gaussian splatting for real-time radiance field rendering,”ACM Transactions on Graphics, vol. 42, no. 4, pp. 1–14, 2023

2023
[8]

Mini-splatting: Representing scenes with a constrained number of gaussians,

G. Fang and B. Wang, “Mini-splatting: Representing scenes with a constrained number of gaussians,”arXiv preprint arXiv:2403.14166, 2024

arXiv 2024

Show all 29 references

[9]

Compact 3d gaussian representation for radiance field,

J. C. Lee, D. Rho, X. Sun, J. H. Ko, and E. Park, “Compact 3d gaussian representation for radiance field,”arXiv preprint arXiv:2311.13681, 2023

2023 arXiv
[10]

Lightgaussian: Unbounded 3d gaussian compression with 15x reduction and 200+ fps,

Z. Fan, K. Wang, K. Wen, Z. Zhu, D. Xu, and Z. Wang, “Lightgaussian: Unbounded 3d gaussian compression with 15x reduction and 200+ fps,” arXiv preprint arXiv:2311.17245, 2023

2023 arXiv
[11]

Metasapiens: Real-time neural rendering with efficiency-aware pruning and accelerated foveated rendering,

W. Lin, Y . Feng, and Y . Zhu, “Metasapiens: Real-time neural rendering with efficiency-aware pruning and accelerated foveated rendering,” in Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 1...

2025
[12]

Seele: A unified acceleration framework for real-time gaussian splatting,

X. Huang, H. Zhu, Z. Liu, W. Lin, X. Liu, Z. He, J. Leng, M. Guo, and Y . Feng, “Seele: A unified acceleration framework for real-time gaussian splatting,”arXiv preprint arXiv:2503.05168, 2025

2025
[13]

Meta Quest Pro specs

“Meta Quest Pro specs.”
[14]

Apple Vision Pro screen refresh rate is up to 100Hz

“Apple Vision Pro screen refresh rate is up to 100Hz.”
[15]

Effect of frame rate on user experience, performance, and simulator sickness in virtual reality,

J. Wang, R. Shi, W. Zheng, W. Xie, D. Kao, and H.-N. Liang, “Effect of frame rate on user experience, performance, and simulator sickness in virtual reality,”IEEE Transactions on Visualization and Computer Graphics, vol. 29, no. 5, pp. 2478–2488, 2023

2023
[16]

Nvidia jetson orin nx

“Nvidia jetson orin nx.”
[17]

Qualcomm QCS8550/QCM8550 Processors

“Qualcomm QCS8550/QCM8550 Processors.”
[18]

Gscore: Efficient radiance field rendering via architectural support for 3d gaussian splatting,

J. Lee, S. Lee, J. Lee, J. Park, and J. Sim, “Gscore: Efficient radiance field rendering via architectural support for 3d gaussian splatting,” in Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volu...

2024
[19]

Potamoi: Accelerating neural rendering via a unified streaming architecture,

Y . Feng, W. Lin, Z. Liu, J. Leng, M. Guo, H. Zhao, X. Hou, J. Zhao, and Y . Zhu, “Potamoi: Accelerating neural rendering via a unified streaming architecture,”ACM Transactions on Architecture and Code Optimization, 2024

2024
[20]

Gsarch: Breaking memory barriers in 3d guassian splatting training via architectural support,

H. He, G. Li, F. Liu, L. Jiang, X. Liang, and Z. Song, “Gsarch: Breaking memory barriers in 3d guassian splatting training via architectural support,” in2025 IEEE International Symposium on High-Performance Computer Architecture (HPCA), IEEE, 2025

2025
[21]

Cicero: Addressing algorithmic and architectural bottlenecks in neural rendering by radiance warping and memory optimizations,

Y . Feng, Z. Liu, J. Leng, M. Guo, and Y . Zhu, “Cicero: Addressing algorithmic and architectural bottlenecks in neural rendering by radiance warping and memory optimizations,” in2024 ACM/IEEE 51st Annual International Symposium on Computer Architecture (ISCA), pp. 1293– 1308,...

2024
[22]

Topological sorting of large networks,

A. B. Kahn, “Topological sorting of large networks,”Communications of the ACM, vol. 5, no. 11, pp. 558–562, 1962

1962
[23]

Cacti 7: New tools for interconnect exploration in innovative off-chip memories,

R. Balasubramonian, A. B. Kahng, N. Muralimanohar, A. Shafiee, and V . Srinivas, “Cacti 7: New tools for interconnect exploration in innovative off-chip memories,”ACM Transactions on Architecture and Code Optimization (TACO), vol. 14, no. 2, pp. 1–25, 2017

2017
[24]

Micron 178-Ball, Single-Channel Mobile LPDDR3 SDRAM Features

“Micron 178-Ball, Single-Channel Mobile LPDDR3 SDRAM Features.”
[25]

Micron System Power Calculators

“Micron System Power Calculators.”
[26]

Deepscaletool: A tool for the accurate estimation of technology scaling in the deep-submicron era,

S. Sarangi and B. Baas, “Deepscaletool: A tool for the accurate estimation of technology scaling in the deep-submicron era,” in2021 IEEE International Symposium on Circuits and Systems (ISCAS), pp. 1– 5, IEEE, 2021

2021
[27]

Neural sparse voxel fields,

L. Liu, J. Gu, K. Zaw Lin, T.-S. Chua, and C. Theobalt, “Neural sparse voxel fields,”Advances in Neural Information Processing Systems, vol. 33, pp. 15651–15663, 2020

2020
[28]

Tanks and temples: Benchmarking large-scale scene reconstruction,

A. Knapitsch, J. Park, Q.-Y . Zhou, and V . Koltun, “Tanks and temples: Benchmarking large-scale scene reconstruction,”ACM Transactions on Graphics (ToG), vol. 36, no. 4, pp. 1–13, 2017

2017
[29]

Deep blending for free-viewpoint image-based rendering,

P. Hedman, J. Philip, T. Price, J.-M. Frahm, G. Drettakis, and G. Bros- tow, “Deep blending for free-viewpoint image-based rendering,”ACM Transactions on Graphics (ToG), vol. 37, no. 6, pp. 1–15, 2018

2018

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

Pharr, W

M. Pharr, W. Jakob, and G. Humphreys,Physically based rendering: From theory to implementation. MIT Press, 2023

2023

[2] [2]

Toward real-time ray tracing: A survey on hardware acceleration and microarchitecture techniques,

Y . Deng, Y . Ni, Z. Li, S. Mu, and W. Zhang, “Toward real-time ray tracing: A survey on hardware acceleration and microarchitecture techniques,”ACM Computing Surveys (CSUR), vol. 50, no. 4, pp. 1–41, 2017

work page 2017

[3] [3]

Nerf: Representing scenes as neural radiance fields for view synthesis,

B. Mildenhall, P. P. Srinivasan, M. Tancik, J. T. Barron, R. Ramamoorthi, and R. Ng, “Nerf: Representing scenes as neural radiance fields for view synthesis,”Communications of the ACM, vol. 65, no. 1, pp. 99–106, 2021

2021

[4] [4]

Mip-nerf: A multiscale representation for anti- aliasing neural radiance fields,

J. T. Barron, B. Mildenhall, M. Tancik, P. Hedman, R. Martin-Brualla, and P. P. Srinivasan, “Mip-nerf: A multiscale representation for anti- aliasing neural radiance fields,” inProceedings of the IEEE/CVF Inter- national Conference on Computer Vision, pp. 5855–5864, 2021

work page 2021

[5] [5]

Recent advances in 3d gaussian splatting,

T. Wu, Y .-J. Yuan, L.-X. Zhang, J. Yang, Y .-P. Cao, L.-Q. Yan, and L. Gao, “Recent advances in 3d gaussian splatting,”arXiv preprint arXiv:2403.11134, 2024

arXiv 2024

[6] [6]

A survey on 3d gaussian splatting,

G. Chen and W. Wang, “A survey on 3d gaussian splatting,”arXiv preprint arXiv:2401.03890, 2024

arXiv 2024

[7] [7]

3d gaussian splatting for real-time radiance field rendering,

B. Kerbl, G. Kopanas, T. Leimk ¨uhler, and G. Drettakis, “3d gaussian splatting for real-time radiance field rendering,”ACM Transactions on Graphics, vol. 42, no. 4, pp. 1–14, 2023

2023

[8] [8]

Mini-splatting: Representing scenes with a constrained number of gaussians,

G. Fang and B. Wang, “Mini-splatting: Representing scenes with a constrained number of gaussians,”arXiv preprint arXiv:2403.14166, 2024

arXiv 2024