Pith. sign in

REVIEW 4 major objections 5 minor 54 references

SLTarch: Towards Scalable Point-Based Neural Rendering by Taming Workload Imbalance and Memory Irregularity

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

Pith's one-line read SLTarch claims that point-based neural rendering can be made scalable on mobile by jointly accelerating LoD search and splatting, reaching 3.9x speedup and 98% energy savings over a mobile GPU.

desk verdict SLTarch is a genuine co-design for LoD search plus splatting, but the headline speedups mix an un-ablated splatting approximation with the hardware gains, so the evaluation needs a second pass before I'd trust the numbers. read the letter →

arxiv 2507.21499 v1 pith:KGO442JY submitted 2025-07-29 cs.AR

classification cs.AR
keywords point-basedneuralrendering3DGaussiansplattinglevel-of-detailsearchhardwareacceleratormobileGPUworkloadimbalancewarpdivergencetreetraversalacceleration
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

Point-based neural rendering renders scenes by splatting learned Gaussians, but on mobile devices it falls short of real-time frame rates. This paper tries to show that the two remaining bottlenecks — level-of-detail (LoD) search and splatting — can be removed together with an algorithm-architecture co-design, rather than by accelerating one stage alone; its measurements put LoD search at up to 70% of execution time on large scenes, where prior accelerators focus only on splatting. The proposed system, SLTarch, balances the irregular LoD tree offline into near-equal subtrees, streams them through a tiny dedicated core, and eliminates warp divergence in splatting by checking Gaussian transparency once per 2 × 2 pixel group. If the paper is right, large-scene neural rendering on mobile becomes 3.9x faster and 98% more energy-efficient than today's mobile GPU, and 1.8x faster with 54% energy savings compared with the existing PBNR accelerator GSCore at similar area, moving large-scene rendering toward VR-class frame rates.

What carries the argument

The load-bearing objects are SLTree, LTcore, and SPcore. SLTree is a subtree-based LoD tree whose offline partitioning and greedy merge cap subtree size at $\tau_s$ so every subtree carries similar work and nodes within a subtree are laid out contiguously. LTcore is a 2 × 2 array of traversal units with a subtree queue, a double-buffered output buffer, and a 4-way set-associative subtree cache; the queue separates loaded from unloaded subtree IDs so units never stall on cache misses, and a skipped subtree is handled by jumping the NID forward by the remaining subtree size. SPcore is the splatting augmentation: one $\alpha$-check unit plus four blending units per SP unit, with a group-level transparency test over 2 × 2 pixel blocks, built on the earlier GSCore design. Together they convert irregular tree walks into streaming DRAM accesses and remove warp divergence in color integration.

What would settle it

Instrument a mobile Ampere GPU running HierarchicalGS with per-stage timers: if LoD search's share is well below 70% at high LoD levels, the LTcore-first architecture loses its motivation. Conversely, build SLTarch on FPGA or test chip and measure it against the same GPU on the same scenes; the 3.9x and 98% claims would not survive if real silicon delivers much less, and the bit-accuracy claim would fall if SLTree traversal ever changes the selected cut compared with the canonical LoD tree.

Watch

Extended reading notes

Core claim

The paper's central discovery is that the irregularity of PBNR can be absorbed at two levels: offline in data layout and online in hardware scheduling. SLTree, the offline-built subtree-based LoD tree, partitions the canonical LoD tree into near-equal subtrees (capped at $\tau_s$ nodes) and stores each subtree's nodes contiguously, so traversal becomes streaming and thread workloads stay balanced; this partition is claimed to preserve the original algorithm's semantics exactly, with bit-identical LoD-search results. LTcore then handles the dynamic part: a 2 × 2 array of traversal units pull subtree IDs from a queue, a subtree cache guarantees loaded data, and a skipped subtree is jumped over using the remaining subtree size. For splatting, the paper's observation that neighboring pixels integrate nearly the same Gaussians leads to a group-level transparency check over 2 × 2 pixel blocks, which removes warp divergence without per-pixel Gaussian-tile tests. The measured consequences are 3.9x speedup and 98% energy savings over a mobile Ampere GPU, 1.8x speedup and 54% energy savings over GSCore, and reductions in DRAM traffic of about 70–76%, at a total area of 1.90 mm² (0.14 mm² for LTcore).

Load-bearing premise

The load-bearing premise is that the simulation and scaling methodology is faithful — mobile-GPU measurements scaled to 16 nm, synthesized accelerator RTL, and DRAM energy models all tracking real hardware well enough for the 3.9x/98% and 1.8x/54% ratios to hold — together with the claim that LoD search really does consume up to 70% of execution time on the HierarchicalGS dataset.

Editorial extensions

If this is right

  • Large-scene PBNR on mobile shifts from splatting-bound to LoD-search-bound as scene size grows; with SLTarch, the LoD-search portion is no longer the scaling wall, so the 3.9x gain is concentrated precisely where existing accelerators do nothing.
  • The SLTree partition can be generated fully offline with no runtime overhead, and because it is semantics-preserving, adopting it does not require retraining or changing the Gaussian model.
  • The SPcore augmentation is a small addition to an existing splatting accelerator such as GSCore — one alpha-check unit and four blending units per pixel group — so prior accelerator designs can inherit divergence-free splatting without a full redesign.
  • On the HierarchicalGS large-scale scenes, LoD search with subtree merging reaches 7.8x speedup over the GPU baseline for the search stage alone, implying the combined pipeline gains come mostly from LTcore.

Reading between the lines

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

  • A natural stress test is to sweep the pixel-group size beyond 2 × 2: the paper's alpha-similarity assumption weakens as groups grow, so there should be a quality/divergence trade-off curve the paper does not report.
  • The same streaming-subtree recipe likely transfers to other irregular tree traversals, such as point-cloud neighborhood search or bounding-volume hierarchies, and the paper's comparison against kd-tree accelerators hints at this generality.
  • The reported 98% energy savings is an end-to-end figure for large scenes; on small scenes where splatting dominates, the paper shows only 2.2x speedup, so the benefit is scene-scale dependent and should be expected to shrink on low-LoD or sparse workloads.
  • Tuning data layout to DRAM row boundaries, which the paper notes is left unaligned, is a direct next step that could close part of the remaining gap between the streaming claim and measured bandwidth behavior.
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.

Referee Report

4 major / 5 minor

Summary. The paper identifies LoD search and splatting as the two dominant bottlenecks in scalable point-based neural rendering (PBNR) and proposes SLTarch, an algorithm-architecture co-design. The SLTree data structure partitions a canonical LoD tree into bounded-size subtrees so that traversal becomes streaming and statically balanced, while the LTcore hardware adds a subtree queue, subtree cache, and dynamic scheduling. For splatting, the SPcore augments a GSCore-style accelerator with a 2x2 pixel-group alpha check that skips color integration for all four pixels when the group-center transparency is below threshold. The evaluation reports 3.9x speedup and 98% energy savings against a mobile Ampere GPU, and 1.8x speedup with 54% energy savings against GSCore, based on simulation, RTL synthesis at 16nm, and GPU measurements scaled with DeepScaleTool.

Significance. If the results hold, this is a meaningful step for PBNR acceleration: it is the first design in the cited literature to address LoD search and splatting jointly, and the SLTree idea of converting irregular tree traversal into streaming, bounded-size subtree workloads is clean and plausibly generalizable. The paper also gives concrete hardware details, reports area (1.90 mm2), includes an ablation of subtree merging, compares against tree-traversal accelerators, and quantifies DRAM traffic reduction. The main weakness is attribution: the SPcore contribution changes the splatting algorithm itself, so the headline speedups combine an approximation with the architectural gain, and the evaluation is limited to one dataset with two scenes. These issues are fixable with additional experiments and more careful claim qualification.

major comments (4)
  1. [Sec. IV-C; Table I; Figs. 9-10] The headline speedups are confounded by an algorithmic approximation. SPcore replaces the per-pixel alpha threshold check with a check at the center of each 2x2 pixel group and, when below threshold, drops the Gaussian for all four pixels (Sec. IV-C). The GPU and GSCore baselines in Sec. V execute the original per-pixel check, so Fig. 9 and Fig. 10 compare an approximate pipeline against exact baselines. Table I shows the quality loss (~0.01 dB PSNR) but does not quantify how much of the speedup comes from the approximation itself. Please add two ablations: (i) a GPU or GSCore baseline that runs the same 2x2 group-level alpha check, and (ii) an exact per-pixel-check variant of SPcore. Without these, the 3.9x and 1.8x numbers cannot be attributed to the architecture, and the claim of 'negligible architecture overhead' is not cleanly supported.
  2. [Sec. III-B; Algorithm 1] Algorithm 1, the SLTree partitioning procedure, is not executable as written. In the second loop, smerge is initialized to an empty set, yet the condition tests smerge.parent() and smerge.size(); when the condition is false, the code pushes smerge and sets scur <- s, but it never assigns scur to smerge or resets smerge after a push. As a result, the merge candidate is undefined, the final S list can include an empty subtree, and the greedy merging behavior shown in Fig. 5 cannot be reproduced. This is load-bearing because the subtree merging ablation in Fig. 12 reports speedups of 3.6x/7.8x with merging versus 2.3x/5.2x without, so the merging algorithm needs a precise, correct specification.
  3. [Sec. V-A and V-C; abstract] The abstract states '3.9x speedup and 98% energy savings' without the qualifier that appears in Sec. V-C: these are large-scale-scene results, while the small-scale results in Fig. 9(a) are 2.2x. Both results are obtained from a single dataset, HierarchicalGS, with two scenes and six scenarios each. Please report the small-scale and large-scale numbers separately in the abstract, state clearly that the evaluation is confined to HierarchicalGS, and, if possible, add a second dataset or at least an explicit discussion of why the chosen scenes are representative. The current wording implies a general claim about scalable PBNR that the evidence does not yet support.
  4. [Sec. V-A] The simulation and scaling methodology needs sensitivity analysis. GPU power and performance are measured on a mobile Ampere GPU and then scaled to 16nm with DeepScaleTool, while the accelerator is synthesized at 16nm and DRAM energy comes from Micron calculators. All headline numbers pass through this mixed flow, but the paper gives no validation of DeepScaleTool for GPU scaling and no sensitivity bounds. Please add a sensitivity study (for example, varying GPU energy/power scaling by +/-30% and re-computing the speedup and energy ratios) and justify that DeepScaleTool is applicable to a full GPU rather than only to the component-level models it was designed for.
minor comments (5)
  1. [Table I] The SSIM column uses a down arrow, but SSIM is higher-is-better; since SLTARCH reports 0.756 versus 0.758 for the original, the arrow should be an up arrow or the table should explain the direction explicitly.
  2. [Sec. V-A] The subtree queue is specified as '1 x 48 B'; this is almost certainly a typo for a number of entries and a width. Please give the exact queue capacity in entries and bits per entry.
  3. [Sec. V-C] The paper motivates real-time rendering with a 60 FPS target in the introduction, but no absolute frame rates are reported anywhere in the evaluation. Please report FPS for the GPU baseline and for SLTARCH so the reader can see whether the target is actually met.
  4. [Sec. V-A] The statement that 'non-streaming and streaming DRAM access is about 3:1' is used without a measurement protocol or citation to a primary source; please provide the methodology or a reference.
  5. [Fig. 12] The legend labels 'S' and 'U' are defined only in the caption and are easy to confuse; consider spelling out 'Speedup' and 'PE utilization' directly in the legend.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the speedups and energy savings are simulator/evaluator results against external baselines (mobile GPU, GSCore), not derivations from the paper's own assumptions.

full rationale

The paper's central claims are evaluated, not derived. SLTarch's 3.9x/98% and 1.8x/54% numbers come from RTL synthesis, GPU measurements, and DRAM/energy models (Sec. V-A), compared against a mobile Ampere GPU and GSCore [22]. No fitted parameter is renamed as a prediction. The LoD-search bottleneck measurement (Sec. II-B) is an experimental observation on the HierarchicalGS dataset, not a premise that already contains the conclusion. The SPcore group-level alpha approximation is an acknowledged algorithmic change (Table I reports ~0.01 dB PSNR drop), and the headline comparisons do not reduce to that approximation by construction; at most, the approximation is confounded with the architectural speedup, which is a correctness/ablation concern, not circularity. Self-citations appear only in related-work comparisons (e.g., Crescent [32], Potamoi [27]) and are not load-bearing for the paper's own contributions. No uniqueness theorem or prior author result is imported to force the design choice. The derivation chain is therefore self-contained with respect to circularity.

Assumptions & free parameters 4 free parameters · 4 assumptions · 0 invented entities

The paper introduces three engineered components (SLTree, LTcore, SPcore) but no unobserved natural entities, so the ledger lists only hand-chosen parameters and domain assumptions. The components' evidence is the simulation in Sec. V; no silicon or independent implementation is provided.

free parameters (4)
  • Subtree size limit tau_s = 32
    Hand-set in Sec. V-A ('we set the subtree size to 32'); controls workload balance, cache footprint, and streaming behavior. No sensitivity analysis across scenes, so the reported speedups depend on this choice.
  • Pixel group size for alpha check = 2x2 pixels
    Chosen in Sec. IV-C as the unit for group-level alpha checks. Larger groups would remove more divergence at higher approximation cost; this value is not derived.
  • LT unit array size and SP unit array size = 2x2 LT units, 2x2 SP units, 1GHz
    Architecture configuration in Sec. V-A; performance and area numbers assume these counts at 1 GHz.
  • Subtree cache and global buffer sizes = 128KB subtree cache, 256KB global buffer
    On-chip memory sizing chosen in Sec. V-A; affects cache miss stalls and DRAM traffic results.
assumptions (4)
  • domain assumption Adjacent pixels integrate similar Gaussian sets, so a single alpha check at the 2x2 group center can replace per-pixel checks without meaningful quality loss.
    Stated in Sec. IV-C and used to justify divergence-free splatting; Table I gives evidence only on the HierarchicalGS dataset.
  • domain assumption LoD search is the dominant bottleneck for large-scale PBNR, up to 70% of execution time.
    Claimed in Sec. II-B and used to motivate LTcore; measured only on the HierarchicalGS dataset with a mobile Ampere GPU.
  • domain assumption SLTree subtree partitioning preserves the cut semantics and bit-accurate results of the canonical LoD tree.
    Asserted in Sec. III-A/III-B; the algorithm skips whole subtrees by incrementing NID with remaining subtree size, which is valid only if the subtree layout exactly preserves the original hierarchy and the size fields are correct.
  • domain assumption DRAM streaming accesses are roughly 3x more energy-efficient than non-streaming accesses, based on prior accelerator papers.
    Used in the energy model in Sec. V-A; the ratio is borrowed from references [44] and [45] rather than measured in this design.

how reviews work

0 comments
Cite this review

Pith. "Pith review of SLTarch: Towards Scalable Point-Based Neural Rendering by Taming Workload Imbalance and Memory Irregularity." pith.science (2026). https://pith.science/paper/KGO442JY

@misc{pith2026250721499,
  author       = {Pith},
  title        = {Pith review of: SLTarch: Towards Scalable Point-Based Neural Rendering by Taming Workload Imbalance and Memory Irregularity},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KGO442JY}},
  note         = {Machine review of arXiv:2507.21499}
}
abstract

Rendering is critical in fields like 3D modeling, AR/VR, and autonomous driving, where high-quality, real-time output is essential. Point-based neural rendering (PBNR) offers a photorealistic and efficient alternative to conventional methods, yet it is still challenging to achieve real-time rendering on mobile platforms. We pinpoint two major bottlenecks in PBNR pipelines: LoD search and splatting. LoD search suffers from workload imbalance and irregular memory access, making it inefficient on off-the-shelf GPUs. Meanwhile, splatting introduces severe warp divergence across GPU threads due to its inherent sparsity. To tackle these challenges, we propose SLTarch, an algorithm-architecture co-designed framework. At its core, SLTarch introduces SLTree, a dedicated subtree-based data structure, and LTcore, a specialized hardware architecture tailored for efficient LoD search. Additionally, we co-design a divergence-free splatting algorithm with our simple yet principled hardware augmentation, SPcore, to existing PBNR accelerators. Compared to a mobile GPU, SLTarch achieves 3.9$\times$ speedup and 98\% energy savings with negligible architecture overhead. Compared to existing accelerator designs, SLTarch achieves 1.8$\times$ speedup with 54\% energy savings.

Figures

Figures reproduced from arXiv: 2507.21499 by the authors.

Figure 1
Figure 1. An example of the scalable PBNR pipeline primarily consists of two steps: LoD search and splatting. In LoD search, [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Normalized execution breakdown of PBNR across different LoDs. 4 8 16 32 64 128 256 # of Threads 10 3 10 4 10 5 10 6 # of Visited Nodes [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 5
Figure 5. Comparison SLTREE before and after subtree merging. Before subtree merging, the subtree sizes still vary, leading to workload imbalance. Algorithm 1: Algorithm of SLTREE Partitioning Data: a list of tree nodes N, tree size limit τs Result: a list of subtree S Q ← N.dequeue(), Sinit ← { }; while Q is not empty do i ← Q.dequeue(); sj , Nchild ← BFS(i, N, τs); Sinit.push(sj ); for ni in Nchild do Q.enqueue(ni); end end… view at source ↗
Figures from the paper (5 more)
Figure 6
Figure 6. Figure 6: The overall SLTARCH architecture design. Our design integrates a LoD search accelerator (LTCORE) and a splatting accelerator (SPCORE). LTCORE executes LoD search while SPCORE supports splatting. Subtrees are initially stored off-chip in BFS order and accessed on a subt…
Figure 7
Figure 7. Figure 7: The subtree cache design. Each cache tag is a SID, [PITH_FULL_IMAGE:figures/full_fig_p005_7.png]
Figure 8
Figure 8. Figure 8: The SPCORE architecture design. Overall, SPCORE consists of a projection unit, a duplication unit, a sorting unit, and a set of SP units. By and large, our design is built upon the hardware design of GSCore [22]. Our main contribution is the new splatting unit, SP unit…
Figure 9
Figure 9. Figure 9: Speedup of different hardware variants over GPU [PITH_FULL_IMAGE:figures/full_fig_p007_9.png]
Figure 11
Figure 11. Figure 11: Performance com￾parison of GPU+LT against two prior tree-based accelera￾tors, QuickNN [36] and Cres￾cent [32]. Numbers are nor￾malized against GPU. Small-scale Large-scale 0 2 4 6 8 10 Speedup 0 20 40 60 80 100 PE Utilization (%) w/o Merge (S) w/ Merge (S) w/o Merge (…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

54 extracted references · 53 canonical work pages

  1. [1]

    Bungeenerf: Progressive neural radiance field for extreme multi- scale scene rendering,

    Y . Xiangli, L. Xu, X. Pan, N. Zhao, A. Rao, C. Theobalt, B. Dai, and D. Lin, “Bungeenerf: Progressive neural radiance field for extreme multi- scale scene rendering,” in ECCV, pp. 106–122, Springer, 2022

  2. [2]

    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,” in ICCV, pp. 5855–5864, 2021

  3. [3]

    Bacon: Band-limited coordinate networks for multiscale scene representation,

    D. B. Lindell, D. Van Veen, J. J. Park, and G. Wetzstein, “Bacon: Band-limited coordinate networks for multiscale scene representation,” in CVPR, pp. 16252–16262, 2022

  4. [4]

    Mobilenerf: Exploiting the polygon rasterization pipeline for efficient neural field rendering on mobile architectures,

    Z. Chen, T. Funkhouser, P. Hedman, and A. Tagliasacchi, “Mobilenerf: Exploiting the polygon rasterization pipeline for efficient neural field rendering on mobile architectures,” in CVPR, pp. 16569–16578, 2023

  5. [5]

    Efficientnerf efficient neural radiance fields,

    T. Hu, S. Liu, Y . Chen, T. Shen, and J. Jia, “Efficientnerf efficient neural radiance fields,” in CVPR, pp. 12902–12911, 2022

  6. [6]

    Baking neural radiance fields for real-time view synthesis,

    P. Hedman, P. P. Srinivasan, B. Mildenhall, J. T. Barron, and P. Debevec, “Baking neural radiance fields for real-time view synthesis,” in ICCV, pp. 5875–5884, 2021

  7. [7]

    Driv- inggaussian: Composite gaussian splatting for surrounding dynamic autonomous driving scenes,

    X. Zhou, Z. Lin, X. Shan, Y . Wang, D. Sun, and M.-H. Yang, “Driv- inggaussian: Composite gaussian splatting for surrounding dynamic autonomous driving scenes,” in CVPR, pp. 21634–21643, 2024

  8. [8]

    Gaussian splatting slam,

    H. Matsuki, R. Murai, P. H. Kelly, and A. J. Davison, “Gaussian splatting slam,” in CVPR, pp. 18039–18048, 2024

Show all 54 references
  1. [9]

    Gs-slam: Dense visual slam with 3d gaussian splatting,

    C. Yan, D. Qu, D. Xu, B. Zhao, Z. Wang, D. Wang, and X. Li, “Gs-slam: Dense visual slam with 3d gaussian splatting,” in CVPR, pp. 19595– 19604, 2024

  2. [10]

    Nerf: Neural radiance field in 3d vision, a comprehensive review,

    K. Gao, Y . Gao, H. He, D. Lu, L. Xu, and J. Li, “Nerf: Neural radiance field in 3d vision, a comprehensive review,” arXiv, 2022

  3. [11]

    A survey on 3d gaussian splatting,

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

  4. [12]

    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,” ToG, vol. 42, no. 4, pp. 1–14, 2023

  5. [13]

    A hierarchical 3d gaussian representation for real-time rendering of very large datasets,

    B. Kerbl, A. Meuleman, G. Kopanas, M. Wimmer, A. Lanvin, and G. Drettakis, “A hierarchical 3d gaussian representation for real-time rendering of very large datasets,” TOG, vol. 43, no. 4, pp. 1–15, 2024

  6. [14]

    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, 2024

  7. [15]

    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, 2023

  8. [16]

    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, 2024

  9. [17]

    Pharr, W

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

  10. [18]

    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 , vol. 50, no. 4, pp. 1–41, 2017

  11. [19]

    Hlbvh: Hierarchical lbvh construction for real-time ray tracing of dynamic geometry,

    J. Pantaleoni and D. Luebke, “Hlbvh: Hierarchical lbvh construction for real-time ray tracing of dynamic geometry,” in Proceedings of the Conference on High Performance Graphics , pp. 87–95, 2010

  12. [20]

    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,” CACM, vol. 65, no. 1, pp. 99–106, 2021

  13. [21]

    Rtgs: Enabling real-time gaussian splatting on mobile devices using efficiency-guided pruning and foveated rendering,

    W. Lin, Y . Feng, and Y . Zhu, “Rtgs: Enabling real-time gaussian splatting on mobile devices using efficiency-guided pruning and foveated rendering,” arXiv, 2024

  14. [22]

    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 ASPLOS, pp. 497–511, 2024

  15. [23]

    Octree-gs: To- wards consistent real-time rendering with lod-structured 3d gaussians,

    K. Ren, L. Jiang, T. Lu, M. Yu, L. Xu, Z. Ni, and B. Dai, “Octree-gs: To- wards consistent real-time rendering with lod-structured 3d gaussians,” arXiv preprint arXiv:2403.17898 , 2024

  16. [24]

    Nvidia jetson orin,

    “Nvidia jetson orin,” 2023

  17. [25]

    Meta Quest Pro specs,

    “Meta Quest Pro specs,” 2023

  18. [26]

    Apple Vision Pro screen refresh rate is up to 100Hz,

    “Apple Vision Pro screen refresh rate is up to 100Hz,” 2024

  19. [27]

    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,” TACO, 2024

  20. [28]

    Vr-pipe: Streamlining hardware graphics pipeline for volume rendering,

    J. Lee, J. Kim, J. Park, and J. Sim, “Vr-pipe: Streamlining hardware graphics pipeline for volume rendering,” arXiv, 2025

  21. [29]

    Uni-render: A unified accelerator for real-time rendering across diverse neural renderers,

    C. Li, S. Li, L. Jiang, J. Zhang, and Y . C. Lin, “Uni-render: A unified accelerator for real-time rendering across diverse neural renderers,” arXiv, 2025

  22. [30]

    Gaussian blending unit: An edge gpu plug-in for real-time gaussian-based rendering in ar/vr,

    Z. Ye, Y . Fu, J. Zhang, L. Li, Y . Zhang, S. Li, C. Wan, C. Wan, C. Li, S. Prathipati, et al. , “Gaussian blending unit: An edge gpu plug-in for real-time gaussian-based rendering in ar/vr,” arXiv, 2025

  23. [31]

    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,” in HPCA, IEEE, 2025

  24. [32]

    Crescent: taming memory irregularities for accelerating deep point cloud analytics,

    Y . Feng, G. Hammonds, Y . Gan, and Y . Zhu, “Crescent: taming memory irregularities for accelerating deep point cloud analytics,” in ISCA, pp. 962–977, 2022

  25. [33]

    Tigris: Architecture and algorithms for 3d perception in point clouds,

    T. Xu, B. Tian, and Y . Zhu, “Tigris: Architecture and algorithms for 3d perception in point clouds,” in MICRO, pp. 629–642, 2019

  26. [34]

    Multidimensional binary search trees used for associative searching,

    J. L. Bentley, “Multidimensional binary search trees used for associative searching,” CACM, vol. 18, no. 9, pp. 509–517, 1975

  27. [35]

    Geometric modeling using octree encoding,

    D. Meagher, “Geometric modeling using octree encoding,” Computer graphics and image processing , vol. 19, no. 2, pp. 129–147, 1982

  28. [36]

    Quicknn: Memory and perfor- mance optimization of kd tree based nearest neighbor search for 3d point clouds,

    R. Pinkham, S. Zeng, and Z. Zhang, “Quicknn: Memory and perfor- mance optimization of kd tree based nearest neighbor search for 3d point clouds,” in HPCA, pp. 180–192, IEEE, 2020

  29. [37]

    Parallelnn: A parallel octree-based nearest neighbor search accelerator for 3d point clouds,

    F. Chen, R. Ying, J. Xue, F. Wen, and P. Liu, “Parallelnn: A parallel octree-based nearest neighbor search accelerator for 3d point clouds,” in HPCA, pp. 403–414, IEEE, 2023

  30. [38]

    Streamgrid: Streaming point cloud analytics via compulsory splitting and deterministic termination,

    Y . Feng, Z. Liu, W. Lin, Z. Liu, J. Leng, M. Guo, Z. He, J. Zhao, and Y . Zhu, “Streamgrid: Streaming point cloud analytics via compulsory splitting and deterministic termination,” in ASPLOS, pp. 1189–1202, 2025

  31. [39]

    Efficient collision detection using bounding volume hierarchies of k- dops,

    J. T. Klosowski, M. Held, J. S. Mitchell, H. Sowizral, and K. Zikan, “Efficient collision detection using bounding volume hierarchies of k- dops,” IEEE transactions on Visualization and Computer Graphics , vol. 4, no. 1, pp. 21–36, 1998

  32. [40]

    Obbtree: A hierarchical structure for rapid interference detection,

    S. Gottschalk, M. C. Lin, and D. Manocha, “Obbtree: A hierarchical structure for rapid interference detection,” in Proceedings of the 23rd annual conference on Computer graphics and interactive techniques , pp. 171–180, 1996

  33. [41]

    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,” in ISCAS, pp. 1–5, IEEE, 2021

  34. [42]

    Mobile lpddr4 sdram,

    “Mobile lpddr4 sdram,” 2018

  35. [43]

    Micron system power calculators,

    “Micron system power calculators,” 2018

  36. [44]

    Tetris: Scalable and efficient neural network acceleration with 3d memory,

    M. Gao, J. Pu, X. Yang, M. Horowitz, and C. Kozyrakis, “Tetris: Scalable and efficient neural network acceleration with 3d memory,” in ASPLOS, 2017

  37. [45]

    Ganax: A unified mimd-simd acceleration for generative adversarial networks,

    A. Yazdanbakhsh, K. Samadi, N. S. Kim, and H. Esmaeilzadeh, “Ganax: A unified mimd-simd acceleration for generative adversarial networks,” in ISCA, 2018

  38. [46]

    Nvidia reveals xavier soc details,

    “Nvidia reveals xavier soc details,” 2018

  39. [47]

    Apple A15 Die Shot and Annotation - IP Block Area Analysis,

    “Apple A15 Die Shot and Annotation - IP Block Area Analysis,” 2021

  40. [48]

    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,” ToG, vol. 36, no. 4, 2017

  41. [49]

    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,” ToG, vol. 37, no. 6, pp. 1–15, 2018

  42. [50]

    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, 2023

  43. [51]

    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, 2025

  44. [52]

    Lumina: Real-time neural rendering by exploiting computational redundancy,

    Y . Feng, W. Lin, Y . Cheng, Z. Liu, J. Leng, M. Guo, C. Chen, S. Sun, and Y . Zhu, “Lumina: Real-time neural rendering by exploiting computational redundancy,” in ISCA, pp. 1925–1939, 2025

  45. [53]

    Streaminggs: V oxel-based streaming 3d gaussian splatting with memory optimization and architectural support,

    C. Zhang, Y . Feng, J. Zhao, G. Liu, W. Ding, C. Wu, and M. Guo, “Streaminggs: V oxel-based streaming 3d gaussian splatting with memory optimization and architectural support,” DAC, 2025

  46. [54]

    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 ASPLOS, pp. 669–682, 2025

Pith tools

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