Pith. sign in

REVIEW 5 major objections 4 minor 28 references

3DGauCIM: Accelerating Static/Dynamic 3D Gaussian Splatting via Digital CIM for High Frame Rate Real-Time Edge Rendering

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

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

Pith's one-line read 3DGauCIM renders large-scale dynamic 3D Gaussian scenes at over 200 FPS while drawing 0.28 W for static and 0.63 W for dynamic scenes.

desk verdict First end-to-end dynamic 3DGS accelerator design is a real contribution, but the headline power and FPS numbers are not auditable as reported. read the letter →

arxiv 2507.19133 v1 pith:JD6UIXWQ submitted 2025-07-25 cs.AR

Wei-Hsing Huang , Cheng-Jhih Shih , Jian-Wei Su , Samuel Wade Wang , Vaidehi Garg , Yuyao Kong , Jen-Chun Tien , Nealson Li
show 4 more authors
Arijit Raychowdhury Meng-Fan Chang Yingyan (Celine) Lin Shimeng Yu
This is my paper · ORCID
classification cs.AR
keywords 3DGaussiansplattingdynamic3DGSdigitalcompute-in-memoryalgorithm-hardwareco-designedgerenderingfrustumcullingbucket-bitonicsortlow-poweraccelerator
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

3DGauCIM is an end-to-end algorithm-hardware co-design that aims to make static and dynamic 3D Gaussian splatting render in real time on power-constrained edge devices. It targets four bottlenecks: DRAM traffic from loading all Gaussians for frustum culling, sorting latency from larger dynamic parameter sets, poor on-chip buffer reuse, and the mismatch between 3DGS math and digital compute-in-memory. The paper's three algorithmic techniques—coarse-grid frustum culling that operates without DRAM reads, adaptive tile grouping, and frame-to-frame bucket-interval reuse in sorting—are paired with a DCIM-friendly dataflow that maps exponential, opacity, and color computations into compute-in-memory arrays. On large-scale real-world scenes, the design reports over 200 FPS at 0.28 W for static scenes and 0.63 W for dynamic scenes. If correct, this makes photorealistic dynamic rendering feasible on battery-powered headsets and robots, beating the frame rate of a prior static-scene accelerator [4] and an edge GPU [23] by wide margins.

What carries the argument

The load-bearing mechanism is a stack of four co-designed pieces: DR-FC, a two-stage offline grid partition (temporal then cubic) whose start/end addresses fit in on-chip memory, so frustum culling happens without DRAM reads; ATG, which records Gaussian-tile connection strengths, groups strongly connected tiles with a Union-Find pass to improve SRAM reuse, and selectively regroups only flagged boundary regions when the previous frame's grouping changes; AII-Sort, which initializes the current frame's bucket intervals from the previous frame's sorted boundaries so bucket populations stay near-uniform and sorting runs near amortized O(N) with Bitonic sort inside each bucket; and DD3D-Flow, the DCIM-friendly dataflow that rewrites the Gaussian exponent as $2^{x'}$ via a sign-integer-fraction decouple and computes the fractional part through a 12-bit segmented LUT in DCIM, with opacity and view-dependent color also mapped into DCIM while near-memory units accumulate transmittance. These pieces are tied together by an SRAM buffer partitioned by depth into segments matching the sort buckets, so blending can narrow its search before a cache lookup.

What would settle it

Fabricate or cycle-accurately simulate the full 3DGauCIM system, including the network-on-chip, DRAM controller, and DCIM array timing, and run the static and dynamic large-scale datasets end to end: the claim stands only if the measured FPS stays above 200 and total power remains near 0.28 W static / 0.63 W dynamic at the stated PSNR. A specific pre-silicon check is whether sustained DRAM traffic exceeds LPDDR5 bandwidth or sorting latency exceeds the 5 ms per-frame budget implied by 200 FPS.

Watch

Extended reading notes

Core claim

On its own terms, the discovery is that dynamic 3D Gaussian splatting can be accelerated end to end by exploiting frame-to-frame coherence in both memory access and sorting, and by rewriting the math so it fits digital compute-in-memory. The design partitions Gaussians offline into coarse temporal and cubic grids, so a given camera pose and time let the controller drop out-of-frustum grids before any DRAM read. It then reuses the previous frame's bucket boundaries and tile-group structure to keep sorting near its ideal amortized O(N) behavior and to maximize SRAM buffer reuse. The DCIM-friendly dataflow converts the Gaussian exponent into $e^x = 2^{x'}$ and applies a sign-integer-fraction decouple, so shifts and a small 12-bit segmented LUT replace costly exponential units; opacity and spherical-harmonic color are also stored and computed in the DCIM arrays, while near-memory units accumulate transmittance. The measured consequence, on large-scale real-world static and dynamic datasets, is 214 FPS at 0.28 W and 211 FPS at 0.63 W respectively, with PSNR essentially matching the edge-GPU baseline; to the authors' knowledge this is the first end-to-end accelerator for dynamic 3DGS.

Load-bearing premise

The headline speed and power numbers come from digital simulation plus measured statistics of a separately fabricated 16nm compute-in-memory chip, not from a working 3DGauCIM chip, so the whole result rests on how faithfully that evaluation stack represents real hardware.

Editorial extensions

If this is right

  • If the reported numbers are correct, untethered AR/VR headsets and small robots can render photorealistic dynamic scenes at over 200 frames per second while drawing under a watt, easing the battery constraint that currently limits edge deployment.
  • Because static 3DGS is a special case of the dynamic pipeline, the same chip covers both workloads, and on large-scale static scenes it exceeds the frame rate of the prior static-scene accelerator [4] by more than 2x.
  • The frame-to-frame reuse schemes imply that, after the first frame, rendering cost stays near amortized O(N) under moderate camera motion, giving the system predictable latency rather than worst-case spikes.
  • The DCIM-friendly exponent mapping moves the expensive math (exponentials, opacity, spherical-harmonic color) into the memory arrays, which is the main reason the power budget stays below one watt.
  • With DRAM traffic reduced by roughly 3x in culling and on-chip reuse improved by adaptive grouping, the memory system, not the compute units, becomes the next scaling bottleneck for denser scenes.

Reading between the lines

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

  • The same sign-integer-fraction decomposition could map other transcendental functions used in neural rendering, such as softmax or sigmoid, onto digital compute-in-memory, so this dataflow may transfer to real-time graphics and vision pipelines beyond 3DGS.
  • For fast head rotations or scene cuts, the frame-to-frame reuse assumptions weaken; a natural extension the paper does not evaluate is to keep several cached bucket-interval and tile-group profiles and switch between them using predicted camera velocity.
  • The offline coarse-grid partition suggests a level-of-detail hierarchy: coarser grids could give approximate visibility for culling decisions and bound worst-case latency, which matters for safety-critical or latency-sensitive edge applications.
  • A testable scaling prediction is that doubling the Gaussian count should raise power and latency roughly linearly if DRAM traffic dominates, while the correlation-aware grouping could soften that scaling in scenes with strong temporal coherence.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

5 major / 4 minor

Summary. The paper proposes 3DGauCIM, an algorithm-hardware co-design framework for accelerating static and dynamic 3D Gaussian splatting on edge devices. It introduces three algorithmic optimizations: DRAM-access reduction frustum culling (DR-FC), adaptive tile grouping with posteriori knowledge (ATG), and adaptive interval initialization Bucket-Bitonic sort (AII-Sort), together with a DCIM-friendly dynamic 3DGS dataflow (DD3D-Flow) that maps exponential evaluation and blending onto digital compute-in-memory macros. The evaluation uses RTL synthesis and post-layout simulation for digital logic, measured statistics from a 16nm DCIM prototype chip, and Ramulator 2.0 for LPDDR5. The central claim is that the design exceeds 200 FPS while consuming only 0.28 W for static and 0.63 W for dynamic Large-Scale Real-World scenes.

Significance. If the reported numbers are reproducible, this would be the first demonstrated end-to-end accelerator for dynamic 3DGS at high frame rate and sub-watt power on an edge-class technology, a meaningful step beyond prior static-only accelerators such as GSCore. The algorithmic ideas of exploiting frame-to-frame coherence for frustum culling, tile grouping, and bucket-sort interval initialization are sensible and well motivated by the profiling data, and the use of measured DCIM macro statistics and a standard DRAM simulator is a strength relative to purely paper-level estimates. However, the central contribution is a system-level FPS and power claim, and that claim currently rests on an evaluation stack whose power accounting and internal consistency are not fully documented.

major comments (5)
  1. [Section 4.D and Table I] The static-scene FPS is internally inconsistent: Table I reports 214 FPS for the Large-Scale Real-World Static Scene, while Section 4.D states that the same configuration achieves 203 FPS. Since the headline claim is specific frame-rate numbers, the paper must identify which number is final and ensure that all reported results come from a single, reproducible evaluation pipeline.
  2. [Section 4.D and Table I] The power numbers 0.28 W and 0.63 W are not auditable: Table I gives no component-level breakdown and no statement of whether DRAM power is included. Because DR-FC, ATG, and AII-Sort are explicitly DRAM-traffic reduction techniques, DRAM energy is a first-order component of the sub-watt claim. The paper should report a breakdown across logic, DCIM macros, SRAM, NoC/control, and DRAM, and state explicitly whether DRAM power is included in the totals.
  3. [Section 3.4] The claim that a 12-bit precision fractional component 'maintains Peak Signal-to-Noise Ratio (PSNR) without degradation' is asserted without any supporting experiment. Since the LUT-based DCIM exponential computation is central to the DCIM-friendly dataflow, the authors should provide a figure or table showing PSNR versus LUT precision on the actual static and dynamic datasets used in the paper, including the chosen precision highlighted.
  4. [Sections 3.4 and 4.D] The scaling from the measured 96 Kb DCIM macro in [5] to the 144 KB (dynamic) and 48 KB (static) DCIM capacities used here is not documented. The paper should specify the number of macro instances, operating frequency and voltage, utilization, and how the measured macro energy and throughput are scaled to the system-level DCIM array; without this, the headline power and FPS numbers are not reproducible.
  5. [Section 4] The evaluation reports only aggregate results averaged over the dynamic scenes, with no per-scene breakdown, no error bars, and no ablation isolating the contribution of DR-FC, ATG, AII-Sort, and DD3D-Flow to the final FPS and power. Since the central claim is about end-to-end performance, a per-scene table and an ablation study are needed to establish that the reported 203/211/214 FPS and 0.28/0.63 W figures are stable and correctly attributed.
minor comments (4)
  1. [Section 1] There is a typo: 'Large-Scale Read-World dynamic scenes' should be 'Large-Scale Real-World dynamic scenes'.
  2. [Section 4] The subsection references in the text are inconsistent: Section 4.D refers to 'Section 4.1', but the subsections are labeled A, B, C, and D. Please unify the cross-reference style.
  3. [Table I] Table I would be easier to read if the static and dynamic configurations were given separate column groups with clear headings, because the repeated '3DGauCIM' label in adjacent columns is ambiguous.
  4. [References] References [24] and [25] appear to cite the same NeRF paper under two different venue entries; please verify and merge or disambiguate them.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the central claims are evaluated through simulation and measured component data rather than derived from their own inputs.

full rationale

The paper's headline FPS and power numbers are produced by an explicit evaluation stack (RTL synthesis plus post-layout simulation, measured 16nm DCIM macro statistics from [5], and Ramulator 2.0 for LPDDR5), not by a mathematical derivation from its own definitions. Each algorithmic contribution is tested against a stated baseline: DR-FC is compared with conventional frustum culling that loads all Gaussian data from DRAM, ATG is compared with conventional raster-scan tile ordering, and AII-Sort is compared with uniform-interval Bucket-Bitonic sort. The DCIM macro data from [5] is a measured hardware result from a published ISSCC paper; although the authorship overlaps with the present paper, it is external, falsifiable component-level evidence and does not by itself assert the target system-level FPS or power claims. No parameter is fitted to a subset of the target data and then renamed as a prediction; the chosen configuration (grid size 4, Tile Blocks 4, threshold 0.5, N=8) is a design choice evaluated in the same simulator, and any concern about tuning on the evaluation data would be a reproducibility or overfitting issue rather than circularity. The internal inconsistency between Table I (214 FPS) and Section 4.D (203 FPS) for the static scene, and the absence of a component-level power breakdown, are auditability and correctness risks, not evidence that an output is equivalent to an input by construction. No uniqueness theorem or ansatz is imported from the authors' prior work to force the design choice. Accordingly, the derivation chain is self-contained in the sense required by the circularity analysis, and no circular step is identified.

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

The central performance claims rest on four hand-tuned configuration parameters, three domain assumptions about the workload (temporal coherence and DCIM chip representativeness), and one tooling assumption about simulator fidelity. No new physical entities are introduced.

free parameters (4)
  • DR-FC grid size = 4
    Chosen as 'optimal trade-off between memory overhead and DRAM access reduction' in Section 4.D; speedup varies with grid size (2.94x to 3.66x in Fig. 9).
  • ATG user-defined threshold = 0.5
    Tuned in Section 4.B; threshold 0.5 with Tile Blocks 1 gives optimal DRAM reduction but they select Tile Blocks 4 to balance memory overhead.
  • Tile Blocks = 4
    Selected for ATG and AII-Sort after sensitivity sweep in Section 4.B, trading off memory overhead vs DRAM access.
  • AII-Sort bucket count N = 8
    Chosen in Section 4.D from the N=4,8,16 sweep in Fig. 11; larger N gives more latency reduction.
assumptions (4)
  • domain assumption The 4D Gaussian Splatting formulation (equations 2-10) accurately models dynamic scenes for rendering.
    Invoked in Section 2.1; the accelerator is built around this representation, and its accuracy is taken from prior work [7,8,10] without re-derivation.
  • domain assumption Frame-to-frame coherence in head movement and Gaussian-tile intersections holds for typical users, as characterized by [11].
    This underpins AII-Sort (Section 3.2) and ATG (Section 3.3); if users move faster than the 'extreme condition' of 180 deg/s or scene content changes abruptly, the posteriori-knowledge reuse degrades.
  • domain assumption The measured statistics of the 16nm DCIM prototype chip [5] are representative of the DCIM macro used in 3DGauCIM.
    Invoked in Section 4 to set DCIM power and performance; the chip is from the same group but is not the 3DGauCIM macro, and per-macro configuration differences are not fully specified.
  • domain assumption The cycle-level and DRAM simulators (RTL synth, post-layout sim, Ramulator 2.0) faithfully model the complete system under the given workloads.
    The headline FPS and power are outputs of this stack (Section 4); no full-chip silicon validation is provided, so the numbers are only as good as the model assumptions.

how reviews work

0 comments
Cite this review

Pith. "Pith review of 3DGauCIM: Accelerating Static/Dynamic 3D Gaussian Splatting via Digital CIM for High Frame Rate Real-Time Edge Rendering." pith.science (2026). https://pith.science/paper/JD6UIXWQ

@misc{pith2026250719133,
  author       = {Pith},
  title        = {Pith review of: 3DGauCIM: Accelerating Static/Dynamic 3D Gaussian Splatting via Digital CIM for High Frame Rate Real-Time Edge Rendering},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JD6UIXWQ}},
  note         = {Machine review of arXiv:2507.19133}
}
read the original abstract

Dynamic 3D Gaussian splatting (3DGS) extends static 3DGS to render dynamic scenes, enabling AR/VR applications with moving objects. However, implementing dynamic 3DGS on edge devices faces challenges: (1) Loading all Gaussian parameters from DRAM for frustum culling incurs high energy costs. (2) Increased parameters for dynamic scenes elevate sorting latency and energy consumption. (3) Limited on-chip buffer capacity with higher parameters reduces buffer reuse, causing frequent DRAM access. (4) Dynamic 3DGS operations are not readily compatible with digital compute-in-memory (DCIM). These challenges hinder real-time performance and power efficiency on edge devices, leading to reduced battery life or requiring bulky batteries. To tackle these challenges, we propose algorithm-hardware co-design techniques. At the algorithmic level, we introduce three optimizations: (1) DRAM-access reduction frustum culling to lower DRAM access overhead, (2) Adaptive tile grouping to enhance on-chip buffer reuse, and (3) Adaptive interval initialization Bucket-Bitonic sort to reduce sorting latency. At the hardware level, we present a DCIM-friendly computation flow that is evaluated using the measured data from a 16nm DCIM prototype chip. Our experimental results on Large-Scale Real-World Static/Dynamic Datasets demonstrate the ability to achieve high frame rate real-time rendering exceeding 200 frame per second (FPS) with minimal power consumption, merely 0.28 W for static Large-Scale Real-World scenes and 0.63 W for dynamic Large-Scale Real-World scenes. This work successfully addresses the significant challenges of implementing static/dynamic 3DGS technology on resource-constrained edge devices.

Figures

Figures reproduced from arXiv: 2507.19133 by the authors.

Figure 3
Figure 3. The complete pipeline of dynamic 3D GS onto the pixel space. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 4
Figure 4. Overall dataflow and hardware architecture of dynamic 3DGS accelerator. [PITH_FULL_IMAGE:figures/full_fig_p007_4.png] view at source ↗
Figure 5
Figure 5. Offline coarse-grain DRAM-access reduction frustum culling. [PITH_FULL_IMAGE:figures/full_fig_p007_5.png] view at source ↗
Figures from the paper (6 more)
Figure 6
Figure 6. Figure 6: Adaptive Interval Initialization Bucket-Bitonic Sort with the posteriori knowledge. [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]
Figure 7
Figure 7. Figure 7: Adaptive tile grouping with the posteriori knowledge. [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: DCIM [5] friendly dynamic 3D Gaussian Splatting dataflow. [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]
Figure 9
Figure 9. Figure 9: Comparison of normalized DRAM access count between proposed DR-FC and conventional method across different grid sizes. [PITH_FULL_IMAGE:figures/full_fig_p012_9.png]
Figure 10
Figure 10. Figure 10: (a) Comparison of normalized DRAM access count between ATG and conventional method. (b) Comparison of normalized [PITH_FULL_IMAGE:figures/full_fig_p012_10.png]
Figure 11
Figure 11. Figure 11: Comparison of normalized sorting latency between proposed AII-Sort and conventional method in average and extreme [PITH_FULL_IMAGE:figures/full_fig_p012_11.png]

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

28 extracted references · 21 canonical work pages

  1. [5]

    A 16nm 96Kb Integer/Floating- Point Dual-Mode-Gain-Cell- Computing-in-Memory Macro Achieving 73.3-163.3TOPS/W and 33.2-91.2TFLOPS/W for AI-Edge Devices,

    Win-San Khwa, Ping-Chun Wu, Jui-Jen Wu, Jian-Wei Su, Ho-Yu Chen, Zhao-En Ke, Ting-Chien Chiu, Jun-Ming Hsu, Chiao-Yen Cheng, Yu-Chen Chen, Chung-Chuan Lo, Ren-Shuo Liu, Chih-Cheng Hsieh, Kea-Tiong Tang, Meng-Fan Chang, “A 16nm 96Kb Integer/Floating- Point Dual-Mode-Gain-Cell- Computing-in-Memory Macro Achieving 73.3-163.3TOPS/W and 33.2-91.2TFLOPS/W for A...

    work page 2024

  2. [1]

    Eswaran, M

    M. Eswaran, M. Bahubalendruni, Challenges and opportunities on AR/VR technologies for manufacturing systems in the context of industry 4.0: a state of the art review, J. Manuf. Syst. 65 (2022) 260–278

    work page 2022

  3. [2]

    3D Gaussian splatting for real-time radiance field rendering

    Kerbl, B.; Kopanas, G.; Leimkuehler, T.; Drettakis, G. 3D Gaussian splatting for real-time radiance field rendering. ACM Transactions on Graphics Vol. 42, No. 4. Article No. 139, 2023

    work page 2023

  4. [3]

    A survey on 3D Gaussian splatting

    Chen, G.; Wang, W. A survey on 3D Gaussian splatting. arXiv preprint arXiv:2401.03890, 2024

    arXiv 2024

  5. [4]

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

    2024

  6. [6]

    Dynamic 3d gaus- sians: Tracking by persistent dynamic view synthesis,

    J. Luiten, G. Kopanas, B. Leibe, and D. Ramanan, “Dynamic 3d gaus- sians: Tracking by persistent dynamic view synthesis,” arXiv preprint arXiv:2308.09713, 2023

    arXiv 2023

  7. [7]

    4d gaussian splatting for real-time dynamic scene rendering,

    G. Wu, T. Yi, J. Fang, L. Xie, X. Zhang, W. Wei, W. Liu, Q. Tian, and X. Wang, “4d gaussian splatting for real-time dynamic scene rendering,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, 2024, pp. 20 310–20 320

    2024

  8. [8]

    Real-time photorealistic dynamic scene representation and rendering with 4d gaussian splatting,

    Z. Yang, H. Yang, Z. Pan, and L. Zhang, “Real-time photorealistic dynamic scene representation and rendering with 4d gaussian splatting,” arXiv preprint arXiv:2310.10642, 2023

    arXiv 2023

Show all 28 references
  1. [9]

    Deformable 3d gaussians for high-fidelity monocular dynamic scene reconstruction,

    Z. Yang, X. Gao, W. Zhou, S. Jiao, Y. Zhang, and X. Jin, “Deformable 3d gaussians for high-fidelity monocular dynamic scene reconstruction,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, 2024, pp. 20 331–20 341

    2024

  2. [10]

    4d-rotor gaussian splatting: towards efficient novel view synthesis for dynamic scenes,

    Y. Duan, F. Wei, Q. Dai, Y. He, W. Chen, and B. Chen, “4d-rotor gaussian splatting: towards efficient novel view synthesis for dynamic scenes,” in ACM SIGGRAPH 2024 Conference Papers, 2024, pp. 1–11

    2024

  3. [11]

    Analyzing viewport prediction under different VR interactions,

    T. Xu, B. Han, and F. Qian, “Analyzing viewport prediction under different VR interactions,” in Proc. 15th Int. Conf. Emerg. Netw. Exp. Technol., 2019, pp. 165–171

    2019

  4. [12]

    Compute-in-memory with emerging nonvolatile-memories: Challenges and prospects,

    S. Yu, X. Sun, X. Peng, and S. Huang, “Compute-in-memory with emerging nonvolatile-memories: Challenges and prospects,” in Proc. IEEE Custom Integr. Circuits Conf. (CICC), Mar. 2020, pp. 1–4

    2020

  5. [13]

    Compute-in-Memory chips for deep learning: Recent trends and prospects,

    S. Yu et al., “Compute-in-Memory chips for deep learning: Recent trends and prospects,” IEEE Circuits and Systems Magazine, vol. 21, pp. 31-56, 2021

    2021

  6. [14]

    An Overview of Processing-in-Memory Circuits for Artificial Intelligence and Machine Learning,

    D. Kim et al., “An Overview of Processing-in-Memory Circuits for Artificial Intelligence and Machine Learning,” IEEE Journal on Emerging and Selected Topics in Circuits and Systems, 2022

    2022

  7. [15]

    K. S. Al-Kharabsheh, I. M. AlTurani, A. M. I. AlTurani, and N. I. Zanoon, ‘‘Review on sorting algorithms: A comparative study,’’ Int. J. Comput. Sci. Secur., vol. 7, no. 3, pp. 120–126, 2013

    2013

  8. [16]

    Mahmoud, P

    H. Mahmoud, P. Flajolet, P. Jacquet, M. RPegnier, Analytic variations on bucket selection and sorting, Acta Inform. 36 (9=10) (2000) 735– 760

    2000

  9. [17]

    Sorting networks and their applications,

    K. E. Batcher, “Sorting networks and their applications,” in Proc. Spring Joint Comput. Conf., 1968, pp. 307–314

    1968

  10. [18]

    Bitonic sorting algorithm: A review,

    M. Jain, S. Kumar, and V. Patle, “Bitonic sorting algorithm: A review,” Int. J. Comput. Appl., vol. 113, no. 13, pp. 40–43, 2015. 16

    2015

  11. [19]

    Davidson, Sameh Khamis, Mingsong Dou, and et al

    Sergio Orts-Escolano, Christoph Rhemann, Sean Fanello, Wayne Chang, Adarsh Kowdle, Yury Degtyarev, David Kim, Philip L. Davidson, Sameh Khamis, Mingsong Dou, and et al. Holoportation: Virtual 3d teleportation in real-time. In Annual Symposium on User Interface Software and Tec...

    2016

  12. [20]

    Ramulator 2.0: A modern, modular, and extensible dram simulator,

    H. Luo et al., “Ramulator 2.0: A modern, modular, and extensible dram simulator,” IEEE Computer Architecture Letters, 2023

    2023

  13. [21]

    Neural 3d video synthesis from multi-view video

    Tianye Li, Mira Slavcheva, Michael Zollhoefer, Simon Green, Christoph Lassner, Changil Kim, Tanner Schmidt, Steven Lovegrove, Michael Goesele, Richard Newcombe, et al. Neural 3d video synthesis from multi-view video. In Proceedings of the IEEE/CVF Conference on Computer Vision...

    2022

  14. [22]

    Tanks and temples: Benchmarking large-scale scene reconstruction

    Arno Knapitsch, Jaesik Park, Qian-Yi Zhou, and Vladlen Koltun. Tanks and temples: Benchmarking large-scale scene reconstruction. ACM Transactions on Graphics (SIGGRAPH), 2017

    2017

  15. [23]

    NVIDIA Jetson AGX Orin Series,

    L. S. K., “NVIDIA Jetson AGX Orin Series,” Mar. 2022. Available: https://www.nvidia.com/content/dam/en-zz/Solutions/gtcf21/jetson- orin/nvidia-jetson-agx-orin-technical-brief.pdf

    2022

  16. [24]

    Representing Scenes as Neural Radiance Fields for View Synthesis,

    Ben Mildenhall et al., “Representing Scenes as Neural Radiance Fields for View Synthesis,” ECCV, 2020

    2020

  17. [25]

    NeRF: Representing Scenes as Neural Radiance Fields for View Synthesis,

    Ben Mildenhall et al., “NeRF: Representing Scenes as Neural Radiance Fields for View Synthesis,” Commun. of the ACM, 2020

    2020

  18. [26]

    Neural sparse voxel fields,

    Lingjie Liu, et al., “Neural sparse voxel fields,” Advances in Neural Information Processing Systems (NeurIPS), 2020

    2020

  19. [27]

    Nerfstudio: A modular framework for neural radiance field development

    Tancik, Matthew, et al., "Nerfstudio: A modular framework for neural radiance field development." ACM SIGGRAPH 2023 conference proceedings. 2023

    2023

  20. [28]

    NVIDIA Nsight Systems,

    NVIDIA, "NVIDIA Nsight Systems," 2024, https://developer.nvidia.com/nsight-systems, accessed 2024-05-20

    2024

Pith tools

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