Pith. sign in

REVIEW 4 major objections 5 minor 30 references

Rendering 3D Gaussians on a Graph Processor

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

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

Pith's one-line read 3D Gaussian Splatting rendering can run entirely on a processor with only on-chip SRAM and no external DRAM, by routing each Gaussian across a grid of tiles to the screen region that needs it.

desk verdict First SRAM-only 3DGS renderer is a real but narrow existence proof; the 'no DRAM needed' conclusion outruns the evidence. read the letter →

arxiv 2607.15951 v1 pith:K3GLLPX5 submitted 2026-07-17 cs.GR cs.CVcs.DC

Nicholas Fry , Ignacio Alzugaray , Mark Pupilli , Paul H. J. Kelly , Andrew J. Davison This is my paper
classification cs.GRcs.CVcs.DC
keywords 3DGaussianSplattingSRAM-onlyrenderinggraphprocessorIPUbulksynchronousparallelNEWSgridroutingdatalocalityon-sensorcomputing
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

This paper tries to establish that 3D Gaussian Splatting, the leading real-time radiance field representation, can be rendered without any external DRAM on a massively parallel processor where each core has only local SRAM. The authors implement the full forward pass on a Graphcore IPU, routing Gaussian primitives tile-to-tile over a north-east-west-south mesh so that each Gaussian reaches the tile owning the screen region it overlaps. They show that once data is in place, rendering is embarrassingly parallel, and that for moderate-density scenes the output is near-identical to a GPU baseline. The broader point is that data movement can be made explicit and local, scaling with how much the camera actually changes, which challenges the assumption that global random-access memory is necessary for high-quality novel view synthesis.

What carries the argument

The key mechanism is the NEWS (north-east-west-south) mesh routing plus a tree-pattern 'bloom' protocol running under the Bulk Synchronous Parallel model. Tiles are arranged in a 2D grid matching framebuffer layout; Gaussians migrate one hop per superstep along Manhattan-shortest paths to their anchor tile, then spread to overlapping tiles via horizontal beams and then vertical forwarding, which guarantees no cyclic duplicates. All channel connections and buffer sizes are fixed at compile time, so data movement is explicit and predetermined. This transforms the GPU's implicit global-memory fetch into an explicit, locality-aware routing problem, and it is what makes SRAM-only rendering possib

What would settle it

Render the dense Bonsai scene (273K Gaussians) from a distant viewpoint and compare per-tile Gaussian counts against the 3,200-primitive internal buffer limit; if no tile exceeds the limit and no tiling artifacts appear, the uniformity assumption is not the limiting factor. Alternatively, measure PSNR/SSIM against the GPU baseline on that viewpoint; a large drop in dense regions would falsify the near-identical claim for non-uniform scenes.

Watch

Extended reading notes

Core claim

The central claim is that 3D Gaussian Splatting's forward pass can be executed with only on-chip SRAM, eliminating DRAM access entirely, by replacing the GPU's global memory with a compile-time-defined network of local tile-to-tile exchanges. Each of 1,472 tiles owns a 32×20-pixel slice of the framebuffer in local memory; Gaussians are projected, then routed by Manhattan-distance hops to their anchor tile, then propagated to overlapping neighbours via a horizontal-then-vertical tree pattern to avoid cyclic copying. Each tile sorts its local Gaussians and alpha-composites its slice, with the only host traffic being the view matrix in and the framebuffer out. For scenes of 25K-91K Gaussians fr

Load-bearing premise

The approach assumes Gaussian density is roughly even across the framebuffer so the aggregate on-chip memory (1,472×192 KB) is usable; when a view concentrates Gaussians on a few central tiles, per-tile SRAM and channel capacities overflow, causing dropped primitives and rectangular artifacts.

Editorial extensions

If this is right

  • If correct, 3DGS rendering can run on DRAM-free, locally-connected processors, enabling on-sensor or edge rendering for AR, robotics, and teleoperation where power is limited.
  • Because data movement scales with actual view change, incremental cameras reduce per-frame routing cost; the measured churn-rate is 0.22%–12% for small motions versus ~98% for teleports, meaning locality is exploitable in SLAM and interactive settings.
  • On GPUs, the same logic suggests that direct inter-SM communication could cut DRAM traffic for 3DGS, since routing rather than arithmetic is the bottleneck.
  • The backward pass, needed for training, should exhibit the same locality, with gradients flowing mostly between neighbouring tiles.
  • The paper's discussion points to hierarchical or compressed Gaussian representations and heterogeneous tile roles as ways to extend the approach to larger and denser scenes.

Reading between the lines

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

  • A testable extension: the paper's 'near-identical to GPU' claim is qualitative; measuring PSNR/SSIM on the dense Bonsai scene would quantify how much quality is lost when the uniformity assumption fails.
  • The routing scheme resembles network-on-chip and wafer-scale designs; the same algorithm could be ported to CPU clusters or Cerebras-style architectures for large-scene streaming, where scene data is partitioned across nodes.
  • The tiling artifacts in dense regions suggest that adaptive tile sizes or dynamic repartitioning of framebuffer ownership based on density could recover quality; the paper mentions offloading to host DRAM but not this alternative.
  • If churn-rate truly scales with view change, a predictive or cached routing scheme could pre-fetch Gaussians based on camera velocity, further cutting latency.
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. This paper describes the first implementation of the 3D Gaussian Splatting forward pass on a Graphcore IPU, a processor with 1,472 tiles of local SRAM and no DRAM. Each tile owns a 32x20-pixel region of the 1280x720 framebuffer. Projected Gaussians are routed toward the tile containing their 2D mean using Manhattan hops on a NEWS grid, then propagated to overlapping tiles via a tree pattern; each tile depth-sorts and alpha-composites locally. The evaluation uses 3D Gaussian maps from Gaussian Splatting SLAM (25K-273K Gaussians) and reports ~20 FPS at 27 W, near-identical visual quality for low-density scenes, and bottlenecks including channel saturation, per-tile SRAM capacity, and load imbalance. The paper argues that the same data-locality insights could inform GPU kernel design with direct inter-SM communication.

Significance. If the central claim holds, the paper provides a useful existence proof that a locally connected, DRAM-free MIMD processor can render 3DGS scenes when the per-tile working set fits on-chip. The strengths are the real measurements on an actual IPU (frame time, power, churn rate), the explicit analysis of where the prototype fails (Figs. 10-12), and the honest discussion of the routing stage as data movement. The churn-rate table is a valuable quantification of temporal locality. However, as explained below, the demonstrated regime is narrower than the abstract/conclusion claim, and quality is not numerically verified. The contribution is still significant for the architecture-exploration and on-sensor rendering communities.

major comments (4)
  1. [§5.2, §6, Figs. 10–11] The headline claim in §7 ('3DGS does not fundamentally require DRAM') rests on the aggregate-memory argument in §5.2: 'assuming a scene is evenly distributed, then the relevant capacity is 1,472×192 KB'. This assumption is load-bearing and is contradicted by the paper's own measurements: §6 reports per-tile SRAM overflow and channel saturation, and Fig. 11 shows distant views concentrating Gaussians on central tiles, while Fig. 10 shows dropped Gaussians and rectangular artifacts. As written, the conclusion is only demonstrated for scenes/views whose per-tile working set stays below the ~3,200-Gaussian internal buffer and 400-Gaussian channel limits. Please state this limitation explicitly in the abstract/conclusion and report per-tile occupancy distributions and the exact condition under which no Gaussians are dropped. The central claim would then be an existence proof for low-density,
  2. [§5.3, Fig. 5] The claim that 'the IPU rendering is near-identical to the GPU baseline' is only supported by side-by-side images. No numerical metric (PSNR, SSIM, LPIPS) is reported, and the Bonsai scene (Figs. 8, 10) visibly contains tiling artifacts. Since the paper's scope includes render quality, quantitative comparison vs the GPU baseline at matched viewpoints is needed, at least for the four evaluated scenes and for the artifact-prone dense views. This is a normal expectation for a rendering-systems paper and would also calibrate the meaning of 'near-identical' in the abstract.
  3. [§5.5, Tables 2–3] The timing tables are internally inconsistent as presented. Table 2's Total-max column is 44.40–47.41 ms for the four scenes, yet Table 3 reports an average frame time of 50.55 ms over the same four scenes. The difference (a few ms) is not explained; it may be due to host transfer or the exchange phase, but the reader cannot tell. In addition, frame time, power, and FPS are reported only as averages over 1,440 frames; no standard deviation, min, or max is given, so it is impossible to assess stability. Please reconcile the tables and report variance or per-scene values.
  4. [§4.3, §6.1] The convergence guarantee ('Convergence is guaranteed within max(W,H) supersteps') is stated without qualification, but §6.1 says that exceeding preallocated buffers 'may compromise both performance and render quality', i.e., Gaussians are dropped before reaching their anchor. The guarantee therefore holds only if channels and internal buffers never overflow. This is not a formal flaw if the proof is understood as assuming unbounded buffers, but the paper should say so and connect the guarantee to the capacity limits in §6. Otherwise the reader is led to believe the routing phase is correct even when the system is dropping primitives.
minor comments (5)
  1. [§5.6 vs §6] The sentence 'the bottleneck is alpha blending, not routing or inter-tile bandwidth' appears to conflict with §6 item 1, which identifies inter-tile bandwidth as a bottleneck. Clarify that the former applies to the tested low-density scenes under non-saturated conditions, while §6 discusses dense-view saturation.
  2. [§4.4] The bounding-radius method for the Gaussian bounding box ('three standard deviations of the larger eigenvalue') should cite the original 3DGS paper [KKLD23] or the corresponding derivation, since it is not a contribution of this work.
  3. [§5.2] The capacity calculation assumes 1,472 tiles, but the framebuffer is partitioned into 1,440 tiles. Reconcile this discrepancy or explain how the remaining 32 tiles are used.
  4. [§5.4] The statement that host communication accounts for only 1.6% of total execution time should specify whether this is of wall-clock time per frame and whether it includes the view-matrix upload and framebuffer download, and how it was measured.
  5. [Fig. 11 caption] Specify which scene is analyzed, which viewpoints are shown, and whether the 900-primitive render-buffer limit in that experiment is also used in the main experiments. This would make the workload-distribution analysis reproducible.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the central claims are empirical measurements on a real implementation, with limitations explicitly acknowledged.

full rationale

The paper's central claims are empirical: it implements a known algorithm (3DGS) on a specific SRAM-only MIMD processor and measures bottlenecks, frame times, power, FPS, and churn rates. No parameter is fitted to a target output and then renamed a prediction; the reported FPS, J/frame, churn, and route-convergence properties are either measured or follow from the Manhattan-distance routing construction. The self-citations ([MMKD24], [TAFD26], [Pup23]) provide input scenes, related work, and a baseline to contrast; none is the source of the central conclusion. The statement 'once each Gaussian reaches the right tile, rendering is embarrassingly parallel' is explicitly conditional and is not used to derive the no-DRAM claim; the paper identifies getting data to the tile as the hard part (§5.8). Where the aggregate-memory feasibility argument rests on uniformity ('assuming a scene is evenly distributed', §5.2), the paper does not hide the violation of that assumption: §6 and Figure 11 document per-tile SRAM overflow, channel saturation, dropped Gaussians, and tiling artifacts, and §6.1 warns that exceeding preallocated buffers 'may compromise both performance and render quality.' These are acknowledged scope limitations, not circularity. The GPU inter-SM suggestion is an explicitly speculative extrapolation, not a fitted prediction. Therefore no circular step can be quoted or reduced to the paper's inputs.

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

The central feasibility claim rests on hand-chosen SRAM/channel budgets, on the spatial-uniformity assumption for aggregate memory, and on reusing the standard 3DGS formulation unchanged. No new physical entities (particles, forces, dimensions) are introduced.

free parameters (3)
  • Per-tile NEWS channel capacity = 400 Gaussians per channel (compile-time constant; ~192 KB total for channels)
    Hand-chosen buffer bound in the SRAM split (Section 6, bottleneck 1 and Section 6.1). When exceeded, Gaussian copies are dropped, producing tiling artifacts. Not derived from scene statistics.
  • Per-tile internal storage buffer size = ~192 KB / ~3,200 Gaussians
    Hand-chosen split between channel and storage SRAM (Section 6.1). Overflow causes dropped Gaussians and limits the scene density a tile can render.
  • Framebuffer tile size = 32×20 pixels (1,440 tiles)
    Framebuffer partitioning choice in Section 4.2. It determines routing hop distances and per-tile load balance; no optimization or derivation is given.
assumptions (5)
  • domain assumption 3D Gaussian Splatting and EWA alpha-compositing (Eq. 1) are correct and can be applied unchanged.
    Section 3.1 relies on [KKLD23] and [ZPvBG02]; the IPU pipeline reuses this formulation rather than deriving it.
  • domain assumption The IPU BSP model with compile-time-defined tile-to-tile channels is a faithful proxy for pixel-processor-array / sensor-processor architectures.
    Sections 3.2-3.3 and Table 1 assert structural similarity (local SRAM, explicit communication, no shared address space); this motivates the hardware choice and the broader claims.
  • domain assumption Gaussian primitives can be routed to their anchor tile via Manhattan hops and propagated via the tree bloom without loss, given fixed channel capacities.
    Sections 4.3-4.4 assume channels of fixed compile-time capacity are sufficient; Section 6 admits this fails under density, causing dropped primitives. The convergence guarantee (max(W,H) supersteps) applies only when buffers do not overflow.
  • domain assumption Aggregate SRAM can hold the scene because Gaussian density is roughly uniform across tiles.
    Section 5.2: 'assuming a scene is evenly distributed, then the relevant capacity is 1,472×192 KB'. Figure 11 shows distant views concentrate Gaussians on few central tiles, so the assumption is violated in practice.
  • domain assumption Zeroth-order spherical harmonics (single RGB per Gaussian) are sufficient for the claimed render quality.
    Section 4.5 'Gaussian Representation' simplifies view-dependent colour to reduce per-primitive memory, dropping a component of the original 3DGS appearance model; the effect on quality is not quantified.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Rendering 3D Gaussians on a Graph Processor." pith.science (2026). https://pith.science/paper/K3GLLPX5

@misc{pith2026260715951,
  author       = {Pith},
  title        = {Pith review of: Rendering 3D Gaussians on a Graph Processor},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/K3GLLPX5}},
  note         = {Machine review of arXiv:2607.15951}
}
read the original abstract

We present the first implementation of a 3D Gaussian renderer on an Intelligence Processing Unit (IPU), comprising 1,472 independent tiles with only on-chip SRAM; constraints that approximate properties of efficient sensor-processor architectures. Our input scenes are 3D Gaussian maps from real-world sequences. Each tile 'owns' a screen-space region of the framebuffer; Gaussian primitives are routed to destination tiles via Manhattan-distance hops on a north-east-west-south (NEWS) grid, then distributed to overlapping neighbours in an expanding tree pattern. Computation follows the IPU's Bulk Synchronous Parallel (BSP) model, with inter-tile communication defined at compile time. We show this hardware allows us to exploit spatial and temporal locality by enabling local data transfer between cores. We evaluate the bottlenecks in this SRAM-only implementation: inter-tile bandwidth, per-tile SRAM capacity, and workload imbalance from non-uniform Gaussian density. We analyse how these constraints affect performance and render quality. This exploration raises broader questions for conventional GPUs and 3D representations, suggesting that direct inter-SM (streaming multiprocessor) communication might offer ways to reduce DRAM access in GPU kernels. We discuss these implications for the future of on-sensor and DRAM-free architectures. Project page: https://nmjfry.github.io/ipu-3dgs/

Figures

Figures reproduced from arXiv: 2607.15951 by the authors.

Figure 1
Figure 1. 3D Gaussian rendering on an Intelligence Processing Unit (IPU). [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Kernel execution order for each tile. A Gaussian is kept [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Gaussian ‘blooming’ protocol. The arrow shows the order [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (9 more)
Figure 4
Figure 4. Figure 4: Gaussian ‘blooming’ protocol based on the 2D bounding [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: Qualitative comparison between the GPU 3DGS baseline (left column) and our IPU implementation (right column). Rows, from [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: We show the 2D Mesh routing that is used in the IPU [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: Model memory footprint (bars) and fraction of the model [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: Bonsai scene (272,956 Gaussians). The IPU render captures leaf detail but exhibits tiling artifacts in dense regions where channel [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]
Figure 9
Figure 9. Figure 9: IPU rendering throughput vs. scene complexity at [PITH_FULL_IMAGE:figures/full_fig_p008_9.png]
Figure 10
Figure 10. Figure 10: Tiling artifacts caused by inter-tile channel saturation. In [PITH_FULL_IMAGE:figures/full_fig_p008_10.png]
Figure 11
Figure 11. Figure 11: Analysis of Workload Distribution. We show three different rendered viewpoints of a model. The corresponding distribution of Gaussians across tiles is shown below. ‘Max points’ refers to the number of points on the tile that stores the most points on the grid. For thi…
Figure 12
Figure 12. Figure 12: Inter-tile channel saturation. Each tile’s outgoing NEWS [PITH_FULL_IMAGE:figures/full_fig_p010_12.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

30 extracted references · 2 linked inside Pith

  1. [1]

    : Descriptor-in-pixel: Point-feature tracking for pixel processor arrays

    Bose L., et al. : Descriptor-in-pixel: Point-feature tracking for pixel processor arrays. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR) (2025)

    2025

  2. [2]

    J., Dudek P., Mayol-Cuevas W

    Bose L., Chen J., Carey S. J., Dudek P., Mayol-Cuevas W. : Visual odometry for pixel processor arrays. In Proceedings of the IEEE International Conference on Computer Vision (ICCV) (2017)

    2017

  3. [3]

    J., Dudek P., Mayol-Cuevas W

    Bose L., Chen J., Carey S. J., Dudek P., Mayol-Cuevas W. : A camera that cnns: Towards embedded neural networks on pixel processor arrays. In Proceedings of the IEEE/CVF International Conference on Computer Vision (ICCV) (2019)

    2019

  4. [4]

    J., Dudek P

    Bose L., Chen J., Carey S. J., Dudek P. : Pixel processor arrays for low latency gaze estimation. In 2022 IEEE Conference on Virtual Reality and 3D User Interfaces Abstracts and Workshops (VRW) (2022)

    2022

  5. [5]

    T., Mildenhall B., Verbin D., Srinivasan P

    Barron J. T., Mildenhall B., Verbin D., Srinivasan P. P., Hedman P. : Mip-nerf 360: Unbounded anti-aliased neural radiance fields. CVPR (2022)

    2022

  6. [6]

    : Routing algorithms for network-on-chip

    Chron o. : Routing algorithms for network-on-chip. In International Symposium on Networks-on-Chip (2007)

    2007

  7. [7]

    Dudek P., Hicks P. J. : SCAMP : A programmable analog vision chip. IEEE Transactions on Circuits and Systems I (2005)

    2005

  8. [8]

    : R2e2: low-latency path tracing of terabyte-scale scenes using thousands of cloud cpus

    Fouladi S., Shacklett B., Poms F., Arora A., Ozdemir A., Raghavan D., Hanrahan P., Fatahalian K., Winstein K. : R2e2: low-latency path tracing of terabyte-scale scenes using thousands of cloud cpus. ACM Trans. Graph. (2022)

    2022

Show all 30 references
  1. [9]

    Hot Chips 33 Symposium, 2021

    Graphcore : Graphcore Colossus Mk2 IPU . Hot Chips 33 Symposium, 2021

    2021

  2. [10]

    https://docs.graphcore.ai/projects/poplar-user-guide/, 2023

    Graphcore : Poplar and PopLibs user guide. https://docs.graphcore.ai/projects/poplar-user-guide/, 2023

    2023

  3. [11]

    https://www.graphcore.ai/products/ipu, 2024

    Graphcore : IPU products. https://www.graphcore.ai/products/ipu, 2024. Accessed: 2026

    2024

  4. [12]

    M., Tagliasacchi A

    Govindarajan S., Rebain D., Yi K. M., Tagliasacchi A. : Radiant foam: Real-time differentiable ray tracing. In Proceedings of the IEEE/CVF International Conference on Computer Vision (2025)

    2025

  5. [13]

    : Deep blending for free-viewpoint image-based rendering

    Hedman P., Philip J., Price T., Frahm J.-M., Drettakis G., Brostow G. : Deep blending for free-viewpoint image-based rendering

  6. [14]

    M., Yang G., Scherer S., Ramanan D., Luiten J

    Keetha N., Karhade J., Jatavallabhula K. M., Yang G., Scherer S., Ramanan D., Luiten J. : Splatam: Splat track & map 3d gaussians for dense rgb-d slam. In Proceedings of the IEEE/CVF conference on computer vision and pattern recognition (2024)

    2024

  7. [15]

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

    Kerbl B., Kopanas G., Leimk \"u hler T., Drettakis G. : 3d gaussian splatting for real-time radiance field rendering. ACM Transactions on Graphics (2023)

    2023

  8. [16]

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

    Lee J., et al. : 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 (ASPLOS) (2024)

    2024

  9. [17]

    : Cerebras architecture deep dive: First look inside the hardware/software co-design for deep learning

    Lie S. : Cerebras architecture deep dive: First look inside the hardware/software co-design for deep learning. IEEE Micro (2023)

    2023

  10. [18]

    C., Khailany B

    Li S., Keller B., Lin Y. C., Khailany B. : Gaurast: Enhancing gpu triangle rasterizers to accelerate 3d gaussian splatting. In Proceedings of the 62nd Annual ACM/IEEE Design Automation Conference (2025)

    2025

  11. [19]

    H., Davison A

    Matsuki H., Murai R., Kelly P. H., Davison A. J. : Gaussian splatting slam. In Proceedings of the IEEE/CVF conference on computer vision and pattern recognition (2024)

    2024

  12. [20]

    Murai R., Saeedi S., Kelly P. H. J. : Bit-vo: Visual odometry at 300 fps using binary features from the focal plane. In 2020 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS) (2020)

    2020

  13. [21]

    : On-the-fly reconstruction for large-scale novel view synthesis from unposed images

    Meuleman A., Shah I., Lanvin A., Kerbl B., Drettakis G. : On-the-fly reconstruction for large-scale novel view synthesis from unposed images. ACM Transactions on Graphics (2025)

    2025

  14. [22]

    : Compressed 3d gaussian splatting for accelerated novel view synthesis, 2023

    Niedermayr S., Stumpfegger J., Westermann R. : Compressed 3d gaussian splatting for accelerated novel view synthesis, 2023. http://arxiv.org/abs/2401.02436 arXiv:2401.02436

    2023 arXiv

  15. [23]

    : Neo: Real-time on-device 3d gaussian splatting with reuse-and-update sorting acceleration

    Oh C., Oh S., Hwang J., Kim Y., Sharma H., Park J. : Neo: Real-time on-device 3d gaussian splatting with reuse-and-update sorting acceleration. In Proceedings of the 31st ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Vol...

    2026

  16. [24]

    : Gcc: A 3dgs inference architecture with gaussian-wise and cross-stage conditional processing

    Pei M., Li G., Si J., Zhu Z., Mo Z., Wang P., Song Z., Liang X., Cheng J. : Gcc: A 3dgs inference architecture with gaussian-wise and cross-stage conditional processing. In Proceedings of the 58th IEEE/ACM International Symposium on Microarchitecture (2025)

    2025

  17. [25]

    : Towards neural path tracing in SRAM , 2023

    Pupilli M. : Towards neural path tracing in SRAM , 2023. http://arxiv.org/abs/2305.20061 arXiv:2305.20061

    2023 arXiv

  18. [26]

    M., Bose L., Dudek P., Wetzstein G

    So H. M., Bose L., Dudek P., Wetzstein G. : Pixelrnn: In-pixel recurrent neural networks for end-to-end-optimized perception with neural sensors. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR) (2024)

    2024

  19. [27]

    Tuya Z., Alzugaray I., Fry N., Davison A. J. : Radiant foam rendering on a graph processor, 2026. URL: https://arxiv.org/abs/2601.04382, http://arxiv.org/abs/2601.04382 arXiv:2601.04382

    2026

  20. [28]

    : Famers: An fpga accelerator for memory-efficient edge-rendered 3d gaussian splatting

    Wang Y., Li Y., Chen J., Yu J., Wang K. : Famers: An fpga accelerator for memory-efficient edge-rendered 3d gaussian splatting. In Design, Automation & Test in Europe Conference (DATE) (2025)

    2025

  21. [29]

    : Endogslam: Real-time dense reconstruction and tracking in endoscopic surgeries using gaussian splatting

    Wang K., Yang C., Wang Y., Li S., Wang Y., Dou Q., Yang X., Shen W. : Endogslam: Real-time dense reconstruction and tracking in endoscopic surgeries using gaussian splatting. In International Conference on Medical Image Computing and Computer-Assisted Intervention (2024)

    2024

  22. [30]

    : Ewa splatting

    Zwicker M., Pfister H., van Baar J., Gross M. : Ewa splatting. IEEE Transactions on Visualization and Computer Graphics (2002)

    2002

Pith tools

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