Paper deep dive
From Splats to Silicon: Rethinking Computational Efficiency of 3DGS
Minnan Pei, Qiwei Dong, Yihan Zhou, Gang Li, Yuchen Zhu, Wenju Zhao, Zhongtian Long, Siting Wang, Peisong Wang, Jian Cheng
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 90%
Last extracted: 9/9/2026, 5:58:18 AM
Summary
This paper presents a workload-centric framework to analyze and rethinks the computational efficiency of 3D Gaussian Splatting (3DGS). It connects representation algorithms, GPU runtime optimizations, and hardware architectures by tracing workload patterns across the rendering and update paths. The authors identify that system gains depend on downstream workload reduction, stage-specific granularity, and data transfer costs. They propose a five-count metric (N resident, N active, N pair, N eval, N blend) to characterize workloads and evaluate existing methods, highlighting open problems for future system design.
Entities (15)
Relation Signals (17)
Projection → ispartof → 3DGS Forward Path
confidence 95% · We refer to the three forward stages as Projection, Sorting, and Blending.
Blending → ispartof → 3DGS Forward Path
confidence 95% · We refer to the three forward stages as Projection, Sorting, and Blending.
Sorting → ispartof → 3DGS Forward Path
confidence 95% · We refer to the three forward stages as Projection, Sorting, and Blending.
3D Gaussian Splatting → supports → real-time novel-view synthesis
confidence 95% · supports real-time novel-view synthesis
3D Gaussian Splatting → uses → explicit primitives
confidence 95% · 3D Gaussian splatting (3DGS) represents scenes with explicit primitives
Workload-Centric Framework → connects → hardware architectures
confidence 90% · use a workload-centric framework to connect representation and algorithm research, GPU runtimes, and hardware architectures
Workload-Centric Framework → connects → representation and algorithm research
confidence 90% · use a workload-centric framework to connect representation and algorithm research, GPU runtimes, and hardware architectures
Workload-Centric Framework → connects → GPU runtimes
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:3D Gaussian splatting (3DGS) represents scenes with explicit primitives and supports real-time novel-view synthesis, yet its system efficiency varies substantially across scenes, viewpoints, rendering paths, and platform constraints. Existing studies pursue efficiency through representation and algorithm design, GPU runtime optimization, and architectural support, but their reported gains correspond to different points along the rendering and update paths. Connecting these indicators to end-to-end system benefit requires tracing how each optimization changes Gaussian selection, screen-space work, data movement, and stage or frame time. We therefore use a workload-centric framework to connect representation and algorithm research, GPU runtimes, and hardware architectures and to identify recurring workload patterns. We complement literature analysis with reproduced measurements and controlled GPU profiling of selected implementations, relating workload counts to stage time and memory traffic. Together, these comparisons show that system gains depend on workload reductions reaching downstream execution, granularity matching each stage, and the cost of data transfers, synchronization, and cached results, gradients, and optimizer data. Building on these findings, we discuss more consistent evaluation under rendering-quality constraints and identify key directions for future system design.
Tags
Links
- Source: https://arxiv.org/abs/2609.06157v1
- Canonical: https://arxiv.org/abs/2609.06157v1
Trouble viewing inline? Open PDF directly →
Full Text
94,981 characters extracted from source content.
Expand or collapse full text
PREPRINT1 From Splats to Silicon: Rethinking Computational Efficiency of 3DGS Minnan Pei, Qiwei Dong, Yihan Zhou, Gang Li, Yuchen Zhu, Wenju Zhao, Zhongtian Long, Siting Wang, Peisong Wang, and Jian Cheng ✦ Abstract—3D Gaussian splatting (3DGS) represents scenes with ex- plicit primitives and supports real-time novel-view synthesis, yet its system efficiency varies substantially across scenes, viewpoints, ren- dering paths, and platform constraints. Existing studies pursue efficiency through representation and algorithm design, GPU runtime optimization, and architectural support, but their reported gains correspond to differ- ent points along the rendering and update paths. Connecting these indi- cators to end-to-end system benefit requires tracing how each optimiza- tion changes Gaussian selection, screen-space work, data movement, and stage or frame time. We therefore use a workload-centric frame- work to connect representation and algorithm research, GPU runtimes, and hardware architectures and to identify recurring workload patterns. We complement literature analysis with reproduced measurements and controlled GPU profiling of selected implementations, relating workload counts to stage time and memory traffic. Together, these comparisons show that system gains depend on workload reductions reaching down- stream execution, granularity matching each stage, and the cost of data transfers, synchronization, and cached results, gradients, and optimizer data. Building on these findings, we discuss more consistent evaluation under rendering-quality constraints and identify key directions for future system design. Index Terms—3D Gaussian splatting, workload characterization, GPU runtime, rasterization, sorting, accelerator, hardware co-design. 1 INTRODUCTION 3D scene reconstruction and novel-view synthesis underpin digital twins, extended reality, free-viewpoint media, and robotic perception [1]–[3]. Neural radiance fields (NeRFs) [4] use a continuous neural function to represent scene ge- ometry and appearance, enabling high-quality novel-view synthesis. Their extensive sampling and network queries along camera rays, however, impose high training and rendering costs that limit real-time use [4], [5]. 3D Gaus- sian splatting (3DGS) [6] instead represents a scene with explicit anisotropic 3D Gaussians and renders through pro- jection, depth organization, and transparency compositing. •Minnan Pei, Yihan Zhou, Gang Li, Siting Wang, Peisong Wang, and Jian Cheng are with the Institute of Automation, Chinese Academy of Sciences, and also with the University of Chinese Academy of Sciences (e-mail: peiminnan19@mails.ucas.ac.cn; gang.li@ia.ac.cn). •QiweiDongiswithNanjingUniversity(e-mail:qiwei- dong@smail.nju.edu.cn). •Yuchen Zhu is with Eindhoven University of Technology. •Wenju Zhao and Zhongtian Long are with the School of Computer Science and Technology, Huazhong University of Science and Technology. •Minnan Pei and Qiwei Dong contributed equally to this work. Gang Li is the corresponding author. The explicit representation supports real-time rendering and allows position, scale, rotation, opacity, and appearance to be accessed and manipulated directly [6], [7]. These capabil- ities have broadened 3DGS beyond static novel-view syn- thesis to large-scale reconstruction and dynamic rendering or editing [1], [7], [8], as well as robotic and augmented- reality mapping, digital-twin modeling, and mobile deploy- ment [2], [3], [9]. The resulting application breadth makes efficient execution across heterogeneous platforms a central systems challenge [9]–[12]. The practical performance of 3DGS depends on how view-dependent workloads map onto compute, storage, and bandwidth resources [13]–[16]. A scene commonly contains hundreds of thousands to millions of Gaussian primitives [6], [8], [13]. In the forward path, visibility culling and projection determine screen-space footprints; Sorting expands these into Gaussian–tile associations, which are then sorted and traversed to evaluate and blend pixel contri- butions [6], [13], [14]. Because Gaussian count, screen-space coverage, and per-pixel blending depth vary with the scene and viewpoint, the computation, data access, and parallel load of each stage also change [13], [15], [16]. Training and online operation add gradient reduction, atomic updates, optimizer data, retained sorting or image data, and trans- fers and synchronization across frames or devices [2], [12], [17]–[20]. Understanding 3DGS system efficiency therefore requires tracing how the scene representation generates work along rendering and update paths and how that work translates into computation and storage demand. Efficiency research on 3DGS now spans representations and algorithms, GPU runtimes, and specialized hardware. At the algorithm level, pruning, quantization, compression, and hierarchies reduce model size or the Gaussians pro- cessed for a view [21]–[24]. GPU software instead targets association generation, sorting, tile scheduling, and gradient accumulation [13], [15], [17]. Hardware research extends graphics pipelines or develops specialized dataflows and storage [12], [14], [20], [25]. Existing surveys cover com- pression, applications, and hardware acceleration [26]–[32]. Across these lines of work, reported efficiency metrics char- acterize different points along the rendering and update paths. Model size captures representation cost, association and pixel-evaluation counts quantify per-frame work, and local speedups describe only the measured portion of exe- cution, so no single metric alone characterizes end-to-end arXiv:2609.06157v1 [cs.AR] 5 Sep 2026 PREPRINT2 Algorithmic Optimization GPU Runtime Optimization Architectural Support 2023202420252026 3DGS Compact 3DGS LightGaussianHAC StopThePop FLoD Hybrid Transp. Speedy-Splat Mobile-GS SpeeDe3DGS DISTWAR Taming 3DGS Grendel Balanced 3DGS FlashGS gsplat GS-Scale CLM HiGS Local-GS Seele GSCore GSArchGauRast GBU DHR STREAMINGGS GCC GS-TG REACT3D Neo Vorion Splatonic Nebula DeGS Timeline 2.1 3DGS Execution Path 2.2 Bottleneck Formation in 3DGS 2.3 Taxonomy of Efficient 3DGS Computations 2.4 Workload-Centric Analysis Framework 3.1 Representation Compaction 6.1 Workload Reduction Must Reach the Backend 6.2 Optimal Granularity Is Stage Dependent 6.3 Local Speedups Shift the Bottleneck 7.1 Evaluation under Quality Constraints 7.2 Traceable Workloads and Sustained Operation 7.3 Open Problems for 3DGS Systems Architectural Support for 3DGS Sec. 5 GPU Runtime Optimization Sec. 4 Algorithmic Workload Optimization Sec. 3 Evaluation Principles and Open Issues Sec. 7 Workload Findings and Implications Sec. 6 Understanding 3DGS Efficiency Sec. 2 3.2 View- and Scale-Adaptive Activation 3.3 Screen-Space Work and Rendering Semantics 3.4 Dynamic Scenes and Online Updates 3.5 Algorithmic Design Space 4.1 Spatial Partitioning and List Organization 4.2 Cooperative Scheduling and Synchronization 4.3 Data Placement at Scale 4.4 GPU Runtime Design Space 5.1 Projection and Sorting Support 5.2 Blending and Backward Support 5.3 Conditional Execution for Sparse Workloads 5.4 On-Chip Data and Cross- Frame Reuse 5.5 Architectural Design Space Multi-Scale 3DGSPUP 3D-GSStochasticSplatsMEGS2 VR-Pipe HAC++ WSR Where does the optimization occur？(Sec 3-5)Whatphysical workload changes?(Across Sec 3-5)Howis the change realized?(Within Sec 3-5) Faster-GS TideGSSplaxel Fig. 1. Workload-centric map of efficient 3DGS systems. The upper panels connect Sections 2–7 to the analysis framework, and the lower timeline places representative algorithm, GPU runtime, and architecture studies in approximate chronological order within each year. system performance [13]–[15], [20], [23]. To compare representation and algorithm design, GPU runtimes, and specialized hardware on a consistent basis, we place each study on shared projection–sorting–blending and update paths. We trace the workload from scene rep- resentation and Gaussian selection through association-list construction and pixel processing to compositing, and then examine how the affected operations map to software and hardware. For each study, we record the first affected stage and the resulting change in computation or data movement. We separately identify whether the implementation elimi- nates, reorganizes, remaps, or reuses that work. Compar- isons retain the task, quality setting, platform, and timed operations. Direct numerical comparisons are limited to aligned conditions, while other results support the analysis of mechanisms and trends. Comparing existing studies along the full workload path reveals three recurring workload patterns. (1) The system benefit of an upstream reduction depends on the balance between the downstream computation or data movement it eliminates and the processing it adds. (2) Different stages favor different granularities, and changing granularity re- distributes overhead across stages. (3) Local acceleration changes the cost distribution of the complete task; further optimization therefore requires reassessing which compu- tation, transfers, or updates actually limit performance. We combine literature analysis, reproduced measurements, and controlled GPU profiling to relate workload counts to stage time and memory traffic. We then discuss the applicabil- ity of these observations under quality requirements and sustained operation, leading to open questions for 3DGS systems. Fig. 1 summarizes the survey structure and key milestones. 2 UNDERSTANDING 3DGS EFFICIENCY The computation, storage, and data-movement costs of 3D Gaussian splatting (3DGS) arise when an explicit scene representation is converted into view-dependent rendering work. This section first describes that execution path and explains how its bottlenecks form. It then organizes prior efficiency research and defines the workload vocabulary used throughout the paper. 2.1 3DGS Execution Path A 3D Gaussian stores spatial position, shape, opacity, and appearance. Its center is represented by the meanμ i , and its 3D shape is described by the covariance Σ i . The covari- ance is commonly parameterized by a scale matrix S i and rotation matrix R i : Σ i = R i S i S T i R T i .(1) Appearance combines opacity and view-dependent color. The original 3DGS [6] represents the latter with spher- ical harmonics (SH). For a camera view, the Gaussian center and covariance are projected into image space. The viewing direction determines the SH basis used to evaluate color from the stored coefficients. The screen-space covariance can be summarized as Σ ′ i = J i WΣ i W T J T i ,(2) where W is the camera transform and J i is the local Jacobian of perspective projection at the Gaussian center. The resulting two-dimensional covariance determines the projected footprint and the tiles and pixels that the Gaussian can affect. Standard GPU implementations follow the tile-based path in Fig. 2. Visibility processing selects Gaussians for the current view, and projection produces their screen-space footprints and depths. Each footprint is associated with the tiles that it overlaps, producing explicit Gaussian–tile records. The records are grouped by tile and ordered by depth. Pixel threads then traverse the ordered list of their tile and evaluate Gaussian response, opacity, transmittance, and color contribution. PREPRINT3 Resident Gaussians PROJECTIONSORTINGBLENDING Renderedimage (a) Visibility culling(b) 2D projection (c) Duplication (d) Sorting by depths ⋮ N resident N active N pair N eval N blend x y z Tile Tile 1 Tile 2 Tile 3 Tile 4 Tile 5 ⋮ <Tile 1, Depth> ⋮ <Tile 2, Depth> <Tile 2, Depth> <Tile 3, Depth> <Tile 4, Depth> <Tile 4, Depth> (e) α checking(f) Color blending ⋮ ⋮ ⋮ Tile 1Tile 5 Tile 5 Pixel 1 Pixel 2 Pixel 3 Pixel 4 Pixel 5 ⋮ Accumulate T<Threshold FORWARD Fig. 2. 3DGS forward paths with the five counts used in the analysis. Forward rendering proceeds from Gaussians stored in rendering memory through visibility culling, projection, Gaussian–tile association generation, depth ordering, candidate evaluation, and alpha compositing. For pixel p, let α i (p) denote the effective opacity of Gaussian i. Gaussians covering the same pixel are composed in front-to-back order: C(p) = X i T i (p)α i (p)c i , T i (p) = Y j<i (1− α j (p)). (3) The compositing result is order dependent. Contribution tests can reject weak candidates, and traversal can terminate after accumulated opacity reaches a threshold. Only ac- cepted contributions update pixel color and transmittance. We refer to the three forward stages as Projection, Sorting, and Blending. Projection covers visibility processing, screen- space projection, and footprint construction. Sorting cov- ers Gaussian–tile association generation, grouping by tile, and depth ordering. Blending covers pixel-level Gaussian evaluation and ordered alpha compositing. Forward denotes the complete Projection–Sorting–Blending path. The differ- entiable Backward path propagates image-space losses to Gaussian parameters and accumulates gradients from many pixels. The Update stage then applies parameter and density- control updates [6]. 2.2 Bottleneck Formation in 3DGS 3DGS replaces the repeated ray sampling and network queries of NeRF with an explicit Gaussian representa- tion [6]. Scene geometry and appearance are stored in mil- lions of Gaussians, each described by dozens of parameters. This shift removes network queries but requires the renderer to read Gaussian attributes and rebuild view-dependent work for every frame. As scene scale, output resolution, or projected coverage increases, more Gaussians, association records, and pixel contributions enter the path, increasing computation and data access [13]. On desktop GPUs, these costs limit frame time and throughput. Edge devices have tighter memory, bandwidth, and power budgets, which can prevent the renderer from meeting real-time latency targets. Most inference traffic comes from repeated accesses to Gaussian attributes and from constructing, ordering, and traversing per-frame association records. Studies across platforms and workloads identify pixel- level blending as a major source of inference time [14], [33], [34]. Each pixel traverses depth-ordered Gaussians and repeatedly evaluates responses, opacity, and color contribu- tions. Because Gaussians are distributed irregularly in space, projected association counts and useful blending work vary across tiles. The resulting imbalance reduces SIMT utiliza- tion and locality in attribute accesses [15], [16], [35]. After dedicated support accelerates rasterization, sorting and its DRAM traffic can become the next major cost [36]. The dom- inant bottleneck therefore depends on the scene, platform, and optimization already applied to each stage. Training and online updates introduce additional pres- sures. During backward propagation, gradients from many pixels converge on shared Gaussians, so atomic updates cause memory conflicts and serialized stalls. Gaussian pa- rameters, gradients, and optimizer states also consume more GPU memory as the model grows [20]. Once these data exceed GPU capacity, host–device transfers can dom- inate iteration time [18], [19]. Dynamic scenes must also update Gaussian geometry and appearance over time. Optimization-based SLAM alternates pose estimation, ren- dering, gradient propagation, and map updates across con- secutive frames [1], [12]. Changes in viewpoint, occlusion, or scene content can invalidate previous visibility results, tile associations, and depth order, limiting temporal reuse [12], [36]. Together, these inference and update costs explain why efficiency research intervenes at several points along the system path. 2.3 Taxonomy of Efficient 3DGS Computations Existing studies fall into three main design domains. Repre- sentation and algorithmic methods change stored Gaussian data, the Gaussians selected for a view, or rendering seman- tics. GPU-runtime methods construct and schedule associ- ation lists, pixel traversal, and gradient reduction on pro- grammable processors. Architectural methods assign these computations and their data to specialized units, buffers, and memory. Individual systems can span several domains. We place each study in Sections 3–5 according to its central design contribution. The questions below then trace its end- to-end effects. We examine each study through three linked questions. Where does the optimization occur? The answer identifies the first affected operation in rendering or updating. What physical workload changes? We first trace representation size, per-frame work, data movement, and synchronization. We also track saved depth order, images, gradients, optimizer data, or update masks through later stages. How is the change PREPRINT4 Representation Compaction Adaptive Activation ↓ N active Screen-Space Rendering · ↓ N pair N eval Temporal Updates All N↓ t t+ Δt ↓ N resident Fig. 3. Representative algorithmic interventions in 3DGS, spanning representation compaction, primitive reduction, adaptive activation, screen- space work reduction, and temporal reuse. realized? We classify the implementation as elimination, re- organization, remapping, or reuse. Fig. 3 illustrates the intervention points for the algorith- mic branch. The runtime and architecture sections apply the same reasoning to scheduling, data placement, and hard- ware mapping. Task, quality setting, rendering implemen- tation, platform, and timing scope define the comparison context. Numerical results are compared directly only when these conditions align. Results from unmatched settings are used only to explain mechanisms within each paper’s reported conditions. 2.4 Workload-Centric Analysis Framework To connect individual optimizations with their system ef- fects, we describe the forward path in Fig. 2 using five counts: N resident → N active → N pair → N eval → N blend . They start with Gaussians stored in rendering memory and follow frame selection, screen-space expansion, pixel evalu- ation, and compositing. The arrows show execution order, but the counts need not change monotonically because each stage measures a different work item. At the start of the path, N resident counts the Gaussians stored in the rendering memory pool and directly accessi- ble to the renderer under test. The pool may use device- local, unified, or host-mapped memory, and its memory tier must be reported. In hierarchical or streamed systems, the complete LoD hierarchy may remain on the host, in the cloud, or in external storage. Gaussians outside the measured rendering pool are excluded. Together with the bytes stored per Gaussian, N resident determines the memory required for their attributes. N active counts Gaussians retained after frame selection, visibility culling, and projected-footprint tests. In our con- trolled profiles, these are the distinct Gaussians producing at least one materialized association. This post-projection count excludes rejected inputs that still incur Projection work. Projected footprints are expanded into Gaussian–tile as- sociation records during Sorting. N pair counts the Gaussian– tile association records created by this expansion. One active Gaussian can generate several records. The resulting list volume determines the associated writes, sorting work, and subsequent reads. Depth ordering reorganizes the records without changing their number. When pixel threads traverse tile lists, N eval counts the Gaussian response or contribution tests they execute. A rejected candidate still counts because its test has already run. Only a subset of these evaluations reaches compositing. N blend counts the contributions that pass the tests and update pixel color and transmittance. Within the same frame and backend, N blend ≤ N eval . With the scene, view, resolu- tion, and backend semantics fixed, ideal lossless prefiltering leaves N blend unchanged. The pixel loop reaches the theo- retical lower bound N eval = N blend only when every non- contributing candidate is rejected before evaluation. Work performed by the prefilter must be accounted for separately. The ratios between successive counts vary with scene content, viewpoint, resolution, tile configuration, selection and culling policy, and backend semantics. Reducing one count therefore need not reduce later counts proportionally. The five counts describe stored Gaussians and rendering operations, but system cost also depends on work per item, transfers, synchronization, temporary buffers, cached results, and optimizer data. Backward computation and parameter updates add further cost. Reducing a count saves time or resources only when the implementation performs fewer computations, accesses, synchronization events, or updates. 3 ALGORITHMIC WORKLOAD OPTIMIZATION Algorithms compact stored Gaussians, select a smaller per- frame set, reduce screen-space work, or reuse valid results across frames. These changes improve runtime when they remove downstream computation or data movement. PREPRINT5 10 1 Compression ratio (×) 1 2 3 4 5 6 Matched rendering speedup (x) RMF C3DGS Light PUP+V HAC-L HAC-H Flux-D Flux-P Mobile-NQ (a) Stored bytes 255075 Gaussian reduction (%) 1 2 3 4 5 6 7 Matched rendering speedup (x) RMF C3DGS-P C3DGS-B PUP Speedy HAC-L HAC-H Flux Mobile-tau.2 (b) Primitive count 406080 Active-Gaussian reduction (%) 1.0 1.5 2.0 2.5 3.0 3.5 4.0 Matched rendering speedup (x) FLoD-543 FLoD-432 Hier-tau2 Hier-tau3 (c) Active Gaussians 050 Association reduction (%) 2 0 2 1 2 2 2 3 2 4 Matched rendering speedup (x) gsplat AdRGS FGS-Pre FGS-Full (d) Screen-space pairs Fig. 4. Rendering speedup versus (a) storage compression ratio and percentage reductions in (b) Gaussians, (c) active Gaussians, and (d) Gaussian–tile associations, matched within each source. Similar association reductions can yield different speedups. Bars span minima to maxima; hollow markers indicate contextual comparisons. 3.1 Representation Compaction Representation compaction reduces the number of Gaus- sians stored in rendering memory, N resident , or their stor- age per Gaussian. Pruning removes Gaussians according to their estimated effect on reconstruction. Reducing the Mem- ory Footprint [37] combines sparse regularization, pruning, and quantization; LightGaussian [23] adds SH distillation and vector quantization to importance pruning. Trimming the Fat [38] and MEGS2 [39] further refine pruning cri- teria. PUP 3D-GS [40] estimates reconstruction sensitivity, while Speedy-Splat [41] reduces scoring storage and prunes during training. Coreset pruning [42] provides resolution- dependent approximation guarantees under assumptions about the rendering queries and transmittance. Removing Gaussians reduces N active and later work only in views that would otherwise render them. Attribute compression can reduce storage without changing Gaussian count. Compact 3DGS [22], HAC [24], and Compressed 3DGS [43] compact color or SH data through parameterization, quantization, and entropy cod- ing. CodecGS [44], HAC++ [45], TC-GS [46], and Neu- ralGS [47] require video or entropy decoding, feature recov- ery, hash lookup, or MLP inference. Rendering speed then depends on the cost of recovering attributes and keeping them in memory. File size, decoded memory, Gaussian count, and decoding time therefore need separate mea- surements. Flux-GS [48] combines compaction with mo- bile rendering, where bandwidth and sustained operation also matter. Fig. 4(a)–(b) shows that storage reduction and speedup differ across the within-source comparisons. 3.2 View- and Scale-Adaptive Activation View and resolution determine which part of a scene is needed. Hierarchical 3DGS [21] combines a Gaussian hier- archy with streaming to select the current view’s LoD Gaus- sians. FLoD [49] exposes selectable detail levels, and Multi- Scale 3DGS [50] activates Gaussians by projected coverage and resolution. Each retains a complete multiresolution representation but exposes a smaller set of Gaussians to projection; their footprints determine N pair and pixel work. Perceptual importance can further guide selection. MetaSapiens [51] combines pruning with foveated render- ing to use fewer Gaussians in peripheral regions. Selecting fewer Gaussians saves rendering work but adds hierarchy traversal, per-frame selection, prefetching, and transitions between quality levels. Fig. 4(c) shows that speedup varies with both the selected Gaussians’ projected footprints and the cost of selecting them. 3.3 Screen-Space Work and Rendering Semantics Screen-space methods can reduce candidates or lower eval- uation cost. Easily Integrable Improvements [52] combines tighter culling, adaptive tiles, and faster evaluation over the existing representation. Tighter coverage reduces the associations entering sorting and traversal, whereas faster response evaluation lowers unit cost without necessarily re- ducing N eval . For the association-reduction methods plotted in Fig. 4(d), smaller sorting and traversal inputs accompany speedups of different magnitudes. Ordering and compositing affect image quality as well as workload. StopThePop [53] improves view consistency through finer ordering and culling. 3DGEER [54] constructs candidates for exact volume rendering along rays. Hybrid Transparency [55], WSR [56], and StochasticSplats [57] relax conventional ordering through partial ordering, weighted accumulation, or stochastic estimation. Mobile-GS [9] com- bines revised transparency with compact representation and lightweight decoding. Their speedups therefore need to be assessed together with the resulting images and the com- positing rules used. 3.4 Dynamic Scenes and Online Updates Dynamic rendering and online mapping update geome- try, appearance attributes, or optimizer data over time. SpeeDe3DGS [58] reduces deformation work through tem- poral pruning and motion grouping. Mobile Avatars [59] compresses blendshape parameters with local structure. Their rendering paths add motion-group lookup or blend- shape decoding to each frame. Training and online mapping compute gradients and update parameters through optimization, densification, and pruning. RTGS [60] reuses keyframe and gradient informa- tion for dynamic pixel downsampling and Gaussian prun- ing, reducing forward rendering and parameter updates. PREPRINT6 1 Tile = 4 × 4 Pixel SM 0SM 1 SM 0SM 1 ⋮ ⋮ Static assignment Dynamicscheduling N eval ↓ CPU–GPU tiering Host (CPU) · DRAM GPU HBM prefetch offload Multi-GPU sharding GPU 0 HBM GPU 1 HBM GPU N−1 HBM Spatial Filtering Task Assignment Data Placement at Scale AABB intersection GS-aware intersection Fig. 5. GPU runtime filtering, scheduling, and data placement. Gaussian-aware intersection reduces invalid evaluations, dynamic scheduling redistributes uneven tasks, and CPU–GPU tiering or multi- GPU sharding distributes Gaussian parameters and optimizer data. 3.5 Algorithmic Design Space Algorithmic choices differ in what they remove and how often they must run. Offline pruning can serve many views of a fixed representation, although decoding may still recur during rendering. View selection and screen-space tests adapt to current footprints but must run for each frame. Reusing results from earlier frames avoids some of this work until motion or appearance changes require new results. Compaction, activation, and filtering should therefore be chosen with their decoding and selection costs in mind. Ap- proximate ordering and transparency also require deciding which changes in image quality are acceptable. 4 GPU RUNTIME OPTIMIZATION The GPU runtime organizes the representation and work selected by the algorithm. It builds association lists, sched- ules pixel and gradient tasks, and places parameters and intermediates. Uneven lists, variable pixel traversal, and gradient contention limit SIMT utilization; Gaussian and optimizer arrays strain memory. Fig. 5 summarizes spatial filtering, task assignment, and data placement. 4.1 Spatial Partitioning and List Organization Spatial partitioning groups projected Gaussians into lists for pixel threads to traverse. Large tiles create fewer lists and tasks and can improve reuse, but include more Gaussians outside an individual pixel’s footprint. Fine tiles reduce invalid evaluations at the cost of more lists and scheduling. HiGS [16] uses macro tiles for partitioning and sorting and finer tiles for rasterization. Seele [10] combines view- dependent preprocessing with contribution tests during ras- terization to reduce invalid evaluation on mobile GPUs. Fig. 6(a) shows that fine tiles raise N pair and coarse tiles raise N eval . N blend changes little. Panel (b) shows the corresponding shift between association-path and rasteriza- tion time, with complete GPU time reaching its minimum between the tested extremes. Panel (c) further shows that tile-list imbalance persists across tile sizes. AdR-Gaussian [61] uses tight axis-aligned bounding boxes, while FlashGS [13] refines Gaussian–tile intersection. Both reduce associations, thereby shrinking sorting input, later traversal, and intermediate list traffic. 4.2 Cooperative Scheduling and Synchronization Uneven tile lists and pixel traversal can leave resources idle even when N pair and N eval are unchanged. Footprint coverage and early termination make static mappings prone to warp divergence. Balanced 3DGS [15] redistributes work through dynamic tile assignment and Gaussian parallel ren- dering inside a warp. Local-GS [62] uses parameter hoisting, warp culling, and coherent blending to reuse data and coordinate pixel processing within tiles. Backward propagation accumulates gradients from many pixels into each Gaussian. DISTWAR [17] combines warp reduction with cache cooperation to reduce global atomic updates and contention. Taming 3DGS [63] organizes backward computation around Gaussians, combining gra- dients before writing them back. These approaches replace some global updates with local reduction. Faster-GS [64] combines a refined Gaussian-centric backward pass with a parameter layout that keeps spatially nearby Gaussians close in memory. Fewer global updates and more regular reads can reduce time even when the same gradients must be computed. 4.3 Data Placement at Scale Training stores Gaussian parameters, gradients, optimizer arrays, and rasterization intermediates together. gsplat [65] reduces memory use through its CUDA and PyTorch imple- mentation. For data that exceed GPU capacity, CLM [18] keeps geometric data used for culling on the GPU and attributes and optimizer arrays on the CPU, using micro- batching, prefetching, and caching. GS-Scale [19] coordi- nates CPU–GPU transfers through parameter forwarding and deferred updates. TideGS [66] also uses SSD storage, loading the needed working set onto the GPU and overlap- ping prefetch, computation, and writeback. With multiple GPUs, partitioning determines both local computation and communication. Grendel [67] partitions parameters by Gaussian and rendering by pixel, transferring only the Gaussians each pixel partition needs. Splaxel [68] exchanges local pixel color, transmittance, and depth in- stead, using convex spatial partitions to preserve global blending order. LiteGS [69] and LoBE-GS [70] combine spatial partitioning, dynamic sorting, or block training to organize large-scene training. Rendering can also divide stages between cloud and client. Nebula [71] runs LoD search in the cloud and sends newly required Gaussians to the client for the remaining stages. The client keeps Gaussians needed by successive frames, avoiding repeated transmission of the same data. PREPRINT7 TABLE 1 Representative Algorithmic Methods and Workload Effects Category MethodMechanismWorkloadCondition Representation compaction Reducing Memory Footprint [37] Sparse pruning + quantizationN resident + storage bytesDecoding and training cost, slight quality loss MEGS2 [39]SG representation + unified pruning N resident + storage bytesFine-tuning, platforms unmatched Flux-GS [48]Energy aggregation + mobile compression N resident + stored bytes and traffic Preprocessing, synchronization, thermal context Provable Pruning via Coresets [42] Coreset pruningN resident Theoretical guarantee, no FPS/traffic Compressed 3DGS [43]Pruning + SH/VQ/entropy coding N resident + attribute bytesHardware rasterization, decoding, and QAT Compact 3DGS [22]Masking + compact color + VQN resident + attribute bytesSmall MLP, decoding, and training LightGaussian [23]Pruning + SH distillation + VQN resident + SH bytesPostprocessing and fine-tuning HAC [24]Hash context + entropy codingEncoded bytes + N active Long CPU decoding, context MLP, and training HAC++ [45]Context-enhanced entropy codingEncoded + in-memory attribute bytes Context construction and decoding CodecGS [44]Feature planes + video codingStored + transferred attribute bytes Video decoding and feature recovery Trimming the Fat [38]Iterative importance pruningN resident , N eval Repeated fine-tuning and gradient cost PUP 3D-GS [40]Uncertainty/sensitivity pruningN resident + work on selected Gaussians Quality-constrained pruning Adaptive activation Hierarchical 3DGS [21]Hierarchy + CPU–GPU streaming N resident , N active Hierarchy storage, interpolation, preprocessing MetaSapiens [51]Guided pruning + foveationN active , N eval + trafficCo-design: RTL scheduling contributes FLoD [49]Selectable multilevel representation N resident , N active Quality-dependent LoD, hierarchy training Multi-Scale 3DGS [50]Multiscale Gaussians + coverage filter N active , N eval , N blend Coverage metadata and modest model growth Screen-space work Easily Integrable Improvements [52] Culling + adaptive tiles + fast evaluation N pair , N eval Precomputation and adaptive control StopThePop [53]Hierarchical sort + tighter culling N pair + order errorView consistency, register/SMEM pressure Hybrid Transparency [55] Ordered head + order-independent tail Sorting + ordered blendingQuality-dependent operating point Speedy-Splat [41]Sparse primitive + pixel processing N active , N eval Sparsity, quality, platform Mobile-GS [9]Unordered blend + pruning + decoding N resident + order dataMLP cost, thermal and quality constraints 3DGEER [54]Exact ray renderingRay candidates + N eval Distinct backend semantics and transforms Dynamic updates SpeeDe3DGS [58]Temporal pruning + motion grouping N resident + deformation work Motion clustering + group transforms RTGS [60]Gradient-guided pruning + pixel downsampling N resident , N eval + update work Keyframe and backward-data reuse; hardware co-design Mobile Avatars [59]Blendshape pruning + light decoding N resident + decoding/update work Avatar-specific setting, scatter and MLP cost, thermal limits Symbols follow Section 2. Other entries denote effects outside the five workload counts. Co-designed methods are listed by their primary algorithmic contribution. 4.4 GPU Runtime Design Space Tile size, task assignment, and data placement need to be considered together. Smaller tiles can reduce invalid pixel tests but generate more lists and temporary traf- fic. Gaussian-centric backward computation changes which threads combine gradients and which parameter addresses they access. Fig. 6(d) distinguishes fewer operations from faster exe- cution of the same work. FlashGS [13] and HiGS [16] reduce association or list work and accelerate the measured stages. Local-GS [62] leaves association volume almost unchanged but reduces time through task organization and reuse. For gsplat [65] and CLM [18], reductions in one workload or memory object yield smaller gains when more of the execu- tion path is timed. Counts and timing must therefore cover the same operations. These comparisons are matched within each source and support the mechanisms under its reported conditions. 5 ARCHITECTURAL SUPPORT FOR 3DGS Architectures change where 3DGS operations execute and data reside through GPU extensions, NPU mappings, or dedicated Projection, Sorting, Blending, and Backward dataflows. They must accommodate view-dependent cov- erage, variable tile lists, and depth-ordered compositing. Table 3 summarizes representative workloads, functional coverage, and reported implementations. PREPRINT8 812162432 Tile (px) 0.5 1.0 1.5 2.0 2.5 Work / tile 16 (a) Workload N pair N eval N blend 812162432 Tile (px) 0.5 1.0 1.5 2.0 2.5 Time / tile 16 (b) Timing Assoc.RasterE2E 812162432 Tile (px) 2 4 6 8 10 List imbalance (c) Imbalance 11.11.524816 Work reduction W b /W o 1 1.1 1.5 2 4 8 16 Execution speedup T b / T o FlashGS HiGS Local-GS gsplat CLM Faster-GS asinh scale (d) Reduction impact Fig. 6. Runtime evidence under controlled tile size changes and matched source conditions. Panels (a)–(c) show workload, timing, and tile list imbalance. Panel (d) relates workload reduction to speedup under matched conditions within each source; both axes use asinh((r− 1)/0.05) with ticks labelled by actual ratios r. The Faster-GS point compares the official testbed’s basis and optimized rasterizers under matched inputs, measuring complete forward rendering rather than full training. TABLE 2 Representative GPU Runtime Methods and Workload Effects Category MethodMechanismWork unitEffect Spatial organization FlashGS [13]Tighter tile overlap + compact listsGaussian–tile pairs and listsReduces N pair , sorting, and list traffic Seele [10]Preprocessing + contribution testsPixel candidatesReduces low-contribution pixel work on mobile GPUs HiGS [16]Macro-tile sort + fine-tile rasterization Tiles, lists, and workersTrades N pair against N eval and balances tasks LiteGS [69]Block locality + optimized operatorsSpatial blocks and operatorsImproves locality in large-scene training LoBE-GS [70]Balanced partitioning + visibility cropping Scene partitions and visible Gaussians Removes irrelevant work and balances partitions Cooperative scheduling Balanced 3DGS [15]Dynamic tile scheduling + warp rendering Tiles and warpsReduces imbalance and unit cost DISTWAR [17]Warp reduction + cache cooperationWarps and gradient targetsReduces global atomic updates Taming 3DGS [63]Gaussian-centric backward passGaussians and gradient targets Reorganizes backward work and synchronization Faster-GS [64]Gaussian-centric backward + locality-preserving layout Gradients and parameter blocks Improves gradient accumulation and memory locality Local-GS [62]Parameter hoisting + warp cullingTiles, warps, and pixelsImproves reuse and reduces invalid pixel tests Data placement gsplat [65]Memory-aware CUDA/PyTorch rasterization Parameters, gradients, intermediates Reduces memory use in large training CLM [18]CPU–GPU split + microbatching/prefetching Attributes, optimizer arrays, microbatches Reduces GPU memory use and overlaps transfers GS-Scale [19]Selective offload + deferred updatesParameters, gradients, optimizer data Coordinates transfers and deferred updates Grendel [67]Parameter/pixel partition + sparse all-to-all Multi-GPU partitionsTransfers only required Gaussians Symbols follow Section 2. Each row reports the primary runtime mechanism, work unit, and direct effect. Results are not normalized across papers. 5.1 Projection and Sorting Support Projection determines the screen-space coverage of selected Gaussians. The resulting Gaussian–tile associations are grouped and sorted for rasterization. GSCore [14] combines precise shape intersection, hierarchical sorting, and subtile masks to reduce candidates and skip uncovered regions. GS-TG [72] shares sorting across neighboring tiles while rasterizing each tile independently. STREAMINGGS [73] uses voxel order and hierarchical filtering before loading complete attributes. These designs either shrink the lists to be sorted or reuse an order across tiles, reducing sorting work and list storage. Previously computed order can avoid sorting every list from scratch. Neo [36] locally reorders the previous frame’s lists, and GSAcc [74] uses historical order to overlap stages. LS-Gaussian [75] reuses image regions and sched- ules remaining tiles from predicted load. DeGS [35] instead repacks dependent work into conflict-free packets for issue. 5.2 Blending and Backward Support After sorting, hardware evaluates candidates and accumu- lates pixel color and transmittance. GauRast [25] adds Gaus- sian evaluation and accumulation to a triangle rasterizer, leaving preprocessing and sorting on CUDA cores. GBU [11] combines a row-organized tile engine, Gaussian reuse cache, and local pixel buffer. Both accelerate the processing of or- dered candidates. Nebula [71] also shares preprocessing and PREPRINT9 TABLE 3 Representative 3DGS Hardware Designs: Work Objects, Mechanisms, and Reported Results Category DesignWork objectMechanism and direct effectCoverageImplementationReported resources/results GPU extension GauRast [25]Candidates; pixel accumulators Rasterizer extension accelerates evaluation/accumulation; Projection and Sorting remain on CUDA BlendingRTL + post-layout; 28 nm A: —; S: — 24 FPS; 1.7 W GBU [11]Ordered candidates; pixel accumulators Row-wise engine caches Gaussian attributes and keeps pixel sums local BlendingRTL + cycle model; 28 nm A: 0.90 m 2 ; S: 63 KB 92 FPS; 0.22 W Integrated GPU Vorion [76]Pixel accumulators; gradients Rasterizer locally accumulates color/alpha gradients; remaining work runs on SIMT Blending, Backward Silicon + FPGA; 16 nm A: 1.60 m 2 ; S: — 6.4–19 FPS; < 0.6 W Dedicated accelerator GSCore [14]Associations; subtile candidates Shape overlap tests/subtile masks skip uncovered work; hierarchical sorting orders retained associations ForwardRTL + cycle/memory; 28 nm A: 3.95 m 2 ; S: 272 KB 91.2 FPS; 0.87 W GS-TG [72]Neighboring tiles’ depth lists Shared order reduces repeated sorting across tiles; rasterization remains per tile ForwardRTL + cycle model; 28 nm A: 3.984 m 2 ; S: 336 KB Relative; 1.063 W FLICKER [77]Pixel candidates; contributions Hierarchical contribution tests and smaller tiles skip unnecessary pixel work ForwardRTL + memory model; 28 nm A: 3.47 m 2 ; S: 288 KB Relative; Relative 129FPS Full-HD [78] Gaussian attributes; pixel candidates Filtering skips pixel work; pre-pruned inputs, reduced SH degree, and quantization compact parameters ForwardRTL + gate-level; 28 nm A: 0.66 m 2 ; S: 120 KB 129 FPS; 0.219 W STREAMING GS [73] Voxel groups; associations Voxel order and hierarchical filtering avoid full-attribute loads for rejected Gaussians ForwardRTL + memory model; 32 nm A: 5.37 m 2 ; S: 355 KB Relative; Relative Neo [36]Previous-frame depth lists Local reordering updates prior-frame lists as views change, avoiding sorting from scratch SortingRTL + memory model; 7 nm A: 0.387 m 2 ; S: 264 KB † 99.3 FPS; 0.798 W GCC [33]Candidate attributes; intermediate lists Streams attributes across stages; failed contribution tests suppress later accesses ForwardRTL + cycle/memory; 28 nm A: 2.711 m 2 ; S: 190 KB 667 FPS; 0.79 W 3DGauCIM [79]Gaussian attributes; pixel accumulators DCIM evaluates Gaussian responses; near-memory units accumulate transmittance ForwardRTL/APR + macro; 16 nm A: 1.81/4.13 m 2 ; S: — 211 FPS; 0.28/0.63 W REACT3D [12]Pixel blocks; gradient updates Post-keyframe block selection limits updates; unreliable prediction restores full Forward Forward, Backward RTL + cycle model; 12 nm A: 12.45 m 2 ; S: 896 KB † 29.15 FPS; 3.55 W Rows distinguish work removal from faster execution, data placement, and reuse. “Forward” denotes Projection, Sorting, and Blending. A: area; S: SRAM; the following line gives throughput and power. Values are extracted from the cited original papers, retaining their reporting scope. “Relative” indicates that no absolute result was reported, and † marks SRAM summed across reported components. GBU evaluates quality and throughput under different settings. 3DGauCIM lists static/dynamic area and power; its throughput is for dynamic scenes. sorting between eyes, adding reprojection, stereo buffers, and list merging to GSCore. Gaussian operations can also use existing graphics and matrix hardware. RayGS [80] uses support quads, standard shaders, and alpha blending. DHR [81] stores partial color and transmittance through programmable blending and supports part of backward computation. VR-Pipe [82] adds hardware early termination, multigranular tile binning, and quad merging to reduce fragment processing and blending. ORANGE [83] maps Gaussian–pixel evaluation to NPU matrix units and uses tile batching to balance work. Training hardware must also combine gradients from different pixels. Vorion [76] integrates a Gaussian rasterizer into a RISC-V GPU, leaving preprocessing, sorting, and remaining gradients on SIMT cores. Cambricon-GS [84] separates Gaussian and pixel computation. GauSPU [85], GSArch [20], and BOA-3DGS [86] use local merging, rear- rangement, or dedicated accumulation to reduce irregular gradient writes. Buffers that hold pixel accumulators during N eval and N blend work serve a different purpose from the storage and routing needed to combine gradients for the same Gaussian. 5.3 Conditional Execution for Sparse Workloads Early tests can skip uncovered regions or negligible contri- butions, avoiding later attribute access, sorting, evaluation, and blending. FLICKER [77] uses hierarchical contribution tests and smaller tiles to remove unnecessary pixel work. The 129FPS Full-HD accelerator [78] combines filtering with pruning, reduced SH degree, and quantization. Online systems expose more dynamic sparsity. RE- ACT3D [12] performs a full forward pass for a new keyframe, then selects pixel blocks for later updates and returns to full forward rendering when prediction is un- reliable. SPLATONIC [87], RTGS [60], and Garnet [88] use sampling, keyframes, gradients, or history to limit tracking and mapping work. The point of rejection determines which work is avoided. Gaussian-level filtering lowers N active and can reduce N pair and attribute traffic. Gaussian–tile tests directly reduce N pair and sorting. Pixel tests lower N eval only when applied before response evaluation. Once that evaluation has begun, rejecting the contribution can still lower N blend , but the test already counts toward N eval . PREPRINT10 5.4 On-Chip Data and Cross-Frame Reuse Keeping attributes and intermediate lists on chip can avoid writing them to external memory and reading them back in later stages. GCC [33] streams attributes across stages and stops later access after a failed contribution test. STREAM- INGGS [73] first filters with compact geometry and voxel data, then loads full attributes only for accepted Gaussians. Neural-3DGS Processor [89] reuses voxel parameters and features across neighboring tiles. The first two designs avoid loading data that later computation will not use; cross-tile reuse avoids loading the same data repeatedly. Computation can also be placed near the data it uses. 3DGauCIM [79] maps Gaussian response evaluation to dig- ital compute-in-memory and accumulates transmittance in near-memory units. IRIS [90] organizes on-chip buffers and external access around Gaussian locality, keeping repeatedly accessed Gaussian data close to the processing units. Cross-frame reuse can save sorting and pixel computa- tion. Neo [36] locally reorders the previous frame’s depth lists as the view changes. Lumina [91] retains predicted order and radiance. Its radiance cache looks up pixel values using the identifiers of the first few Gaussians along a ray whose contributions exceed a threshold: a hit reuses the cached value, while a miss continues rasterization. DF- SAR [92] preserves alpha values, voxel data, or keyframes across SLAM. 5.5 Architectural Design Space Hardware grouping should follow the data being processed. Sorting can share order across voxels or tile groups, while pixel evaluation can reuse attributes within rows, tiles, or subtiles. Larger groups may reduce repeated work but need more buffer space and can delay a stage that must wait for the group to finish. Local graphics extensions and NPU mappings reuse existing interfaces and leave other stages programmable. Dedicated hardware can coordinate filtering, sorting, and accumulation, but must buffer intermediate lists and pass them between stages in the required order. Across views, training iterations, and online updates, it must also re- place cached parameters or results when they change. Pro- grammable components can adjust parameter updates and compositing rules as representations evolve. 6 WORKLOAD FINDINGS AND IMPLICATIONS Sections 3–5 show how algorithms, runtimes, and hardware improve efficiency by changing the amount of work, ex- ecution organization, and resource use. We now examine how these changes affect later execution, why stages favor different granularities, and which costs remain after local acceleration. 6.1 Workload Reduction Must Reach the Backend Workload counts explain time only when tied to specific operations. In Fig. 7, N active correlates moderately with N pair , whereas N pair and N eval more directly track sorting and rasterization time. Active Gaussian count alone thus cannot describe downstream cost. Association and evalu- ation counts better reflect executed operations, although their explanatory power depends on implementation and configuration. The same input can lead to different operations and memory accesses. In Fig. 8, gsplat reduces the median as- sociation count by about 42% relative to Graphdeco, but in- dependently measured complete forward time falls by only 4%, while DRAM traffic rises by 19%. The reduction reaches radix sorting: median traffic in its kernels falls from 0.58 to 0.34 GB. However, gsplat also gathers attributes, includ- ing positions, opacities, and spherical-harmonic coefficients, into compact arrays. A separate kernel evaluates colors from the gathered coefficients, whereas Graphdeco performs this evaluation within its Projection kernel. Generic indexing kernels collectively transfer a median of 0.47 GB per view, about 27% of gsplat’s total DRAM traffic. Attribute prepa- ration thus warrants attention alongside association con- struction; these kernel-level records identify a substantial traffic source without isolating each buffer or explaining the full latency difference. A concrete design option is to retain compact projected records while letting color evaluation consume indexed attributes directly, avoiding intermediate copies. This trades separately materialized compact arrays for indexed access within their consumer, with the net ben- efit to be tested using complete forward timing. The com- bined evidence therefore points to how attributes reach com- putation as an optimization target that association counts or FPS alone would not identify. Culling and intersection rules differ, and Appendix D checks quality differences only for these views. Removalpointdetermineswhichoperationsare avoided. For compression, analysis should check whether decoding preserves any reduction in memory use; culling associations before record construction can avoid their writes and sorting; training sparsity must remove gradi- ent computation or parameter updates. Benefits therefore depend on both operations avoided and added decoding, filtering, and scheduling. 6.2 Optimal Granularity Is Stage Dependent Granularity changes both grouping and total work. In Fig. 6(a)–(c), fine tiles increase associations and list- organization cost, while coarse tiles increase invalid eval- uations and rasterization cost; N blend changes little. Total time is lowest between the tested extremes, so fewer evalu- ations need not mean faster execution. This tradeoff remains specific to the tested scenes and implementation. Successive stages need not share a grouping. HiGS [16] uses macro tiles for partitioning and sorting, then finer tiles for rasterization; GS-TG [72] shares sorting across adjacent tiles but rasterizes them independently. Larger groups can amortize sorting overhead, while smaller pixel-processing groups reduce invalid evaluations. Such designs must also account for list conversion, additional records, and schedul- ing. Granularity also depends on the work item. Cov- erage, view, and task distribution alter grouping and load-balancing benefits. Splaxel [68] replaces inter-device Gaussian-parameter communication with local pixel aggre- gates. Its tradeoff concerns transmitted data and composit- ing order, so conclusions about rasterization tile size do not PREPRINT11 10 5 2×10 5 10 6 2×10 6 N active 10 6 2×10 6 10 7 2×10 7 N pair (a) Active Gaussians to pairs 10 6 2×10 6 10 7 2×10 7 N pair 2×10 −1 10 0 2×10 0 Sorting time (ms) (b) Pairs to sorting time 2×10 8 10 9 2×10 9 N eval 10 0 2×10 0 10 1 2×10 1 Raster time (ms) (c) Evaluations to raster time bicyclebonsaitruckdrjohnson 30K / 800 px / tile 167K / 800 px / tile 1630K / higher res. / tile 1630K / 800 px / tile 830K / 800 px / tile 32 Fig. 7. Workload and kernel-timing relationships under controlled conditions. The panels connect active Gaussians to associations, associations to sorting time, and pixel evaluations to rasterization time, an operation measured within Blending. directly apply. Granularity choices must identify the stage, work item, and added operations. 6.3 Local Speedups Shift the Bottleneck Previously secondary operations can limit further acceler- ation. After optimizing rasterization, Faster-GS [64] finds substantial training time spent on Adam and fuses pa- rameter updates into backward computation. Fusion adds speedup and saves VRAM, but updates remain the main bottleneck. This extends attention to the complete update path. A rising time share alone, however, establishes nei- ther increasing absolute cost nor a dominant bottleneck; complete-iteration timing is still needed. Capacity-limited training and cloud-assisted rendering must also account for transfers. TideGS [66] tiers storage across SSD, CPU, and GPU, loading Gaussian parameters on demand and overlapping prefetch, computation, and writeback to train models exceeding GPU capacity. Neb- ula [71] searches LoD in the cloud and sends newly needed Gaussians to clients for the remaining rendering stages. TideGS requires evaluation over complete training itera- tions; Nebula requires measurements of sustained rendering and interaction latency. Compute speedup cannot substitute for evaluating these transfers. Reuse likewise requires accounting across the complete path. Attribute reuse in Section 5 avoids repeated reads; cross-frame reuse must handle changed results. Neo [36] locally reorders old depth lists, Lumina [91] continues ras- terization on pixel-cache misses, and REACT3D [12] can repeat full forward rendering to recompute the loss map. These operations and stored data occupy resources, while asynchronous overlap may introduce contention. Net ben- efit depends on whether saved computation and accesses outweigh added costs. 7 EVALUATION PRINCIPLES AND OPEN ISSUES Existing studies differ in quality requirements, workloads, and execution. Evaluation must identify the conditions cov- ered by evidence to establish comparability and distinguish findings from unresolved questions. 7.1 Evaluation under Quality Constraints Efficiency comparisons should examine actual output qual- ity. Compression and pruning affect image error; StopThe- Pop [53] addresses view consistency; WSR [56] and Stochas- ticSplats [57] change transparency evaluation. Training ad- ditionally requires checking the final reconstruction: Faster- GS [64] treats skipping invisible-Gaussian updates as op- tional because it differs from strict Adam updates and can change results. Matching settings therefore does not guar- antee matching quality, and faster iterations do not establish final reconstruction quality. Comparison claims must respect each evidence set’s conditions. Figs. 4 and 6(d) match configurations within sources, relating storage, work, and time at the correspond- ing quality. Fig. 8 and Appendix D check quality differences for the same model and views, supporting implementation comparisons within that scope. Neither supports ranking papers evaluated at different quality levels. 7.2 Traceable Workloads and Sustained Operation Experiments must record what generates the workload. Hierarchical and multiscale methods [21], [49], [50] change view-selected Gaussians, while FlashGS [13] changes as- sociations. Fig. 7 examines work–time relationships under controlled conditions, while Fig. 8 holds inputs fixed to examine implementation differences. Both characterize the measured workloads. Sustained behavior also depends on history and op- erating conditions. View sequences affect Neo’s reorder- ing and REACT3D’s full forward recomputation; training views change the Gaussians TideGS loads; Nebula addition- ally depends on cloud–client collaboration. Mobile-GS [9] distinguishes cold and sustained operation. Single-frame measurements or brief FPS averages capture only part of this behavior. Evaluation should cover representative con- tinuous operation, tracking tail latency, sustained power, PREPRINT12 0.5124 count (million, log scale) Graphdeco gsplat FlashGS StopThePop Speedy-Splat Faster-GS (a) Materialized workload Active set Pairs 0255075100 NCU kernel-time share (%) (b) Kernel composition 24 ms (c) Unprofiled forward 0.51.01.5 GB/frame (d) NCU DRAM traffic ProjectionSortingBlendingProjection+SortingOther kernels Fig. 8. Same input across 3DGS backends. Panel (a) shows active Gaussians and materialized pairs; panel (b) groups kernels by Projection, Sorting, and Blending, keeping cross-stage fused kernels joint. Panels (c)–(d) show independently measured complete forward latency and DRAM traffic. Markers are medians over views, and lines span minima to maxima. and periods of concentrated reordering, recomputation, or transfers. 7.3 Open Problems for 3DGS Systems Shared workload interfaces. Fig. 8 shows different as- sociations and accesses for the same input. Shared inter- faces must define Gaussian selection, coverage, and sort results so later stages can reuse results correctly. Open questions concern which information can be shared, which implementation-specific culling and compositing rules must remain, and whether avoiding repeated construction offsets interface conversion and updates. Adaptive execution under varying workloads. The granularity tradeoffs in Fig. 6 and configuration differences in Fig. 7 show that fixed-policy benefits vary with work dis- tribution. HiGS’s stage-specific granularity and dynamic as- signment in Balanced 3DGS [15] offer different approaches. Future work should investigate inexpensive observation of association counts, traversal lengths, or imbalance to ad- just grouping and resources while controlling observation, switching, and list-rebuilding costs. Programmable specialization boundaries. Hardware in Section 5 covers parts of filtering, sorting, evaluation, or updating, while training, dynamic scenes, and cross-frame reuse also require changed selection rules or recomputa- tion. Determining which operations to fix in hardware and which policies to keep programmable requires evaluation of complete tasks. Designs must balance specialized efficiency, functional coverage, and evolving representations rather than only maximize individual-kernel speed. 8 CONCLUSION This paper examines 3DGS algorithms, GPU runtimes, and architectures through a common workload-centric frame- work. No single metric captures end-to-end system behav- ior. Model size describes storage, workload counts distin- guish stored Gaussians from executed work, and kernel timing covers selected code. End-to-end gains depend on where work is removed, how granularity shapes down- stream work, and whether computation, transfers, and up- dates to cached results or optimizer data also decline. A workload-centric view motivates evaluation under rendering-quality constraints with traceable inputs, the same timed operations, and sustained measurements. It also highlights stable workload interfaces, adaptive execution, and programmable specialization as open directions. Fol- lowing work from the representation to backend execution provides a common basis for comparing methods and de- signing integrated systems. REFERENCES [1]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 (CVPR), 2024, p. 20 310–20 320. [Online]. Available: https://openaccess.thecvf. com/content/CVPR2024/html/Wu_4D_Gaussian_Splatting_for_ Real-Time_Dynamic_Scene_Rendering_CVPR_2024_paper.html [2]N. Keetha, J. Karhade, K. M. Jatavallabhula, G. Yang, S. Scherer, D. Ramanan, and J. Luiten, “SplaTAM: Splat Track & Map 3D Gaussians for Dense RGB-D SLAM,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2024, p. 21 357–21 366. [Online]. Available:https://openaccess.thecvf.com/content/CVPR2024/ html/Keetha_SplaTAM_Splat_Track__Map_3D_Gaussians_for_ Dense_RGB-D_CVPR_2024_paper.html [3]J. Guo, Y. Xin, G. Liu, K. Xu, L. Liu, and R. Hu, “ArticulatedGS: Self-supervised Digital Twin Modeling of Articulated Objects using 3D Gaussian Splatting,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2025, p. 27 144–27 153. [Online]. Available: https://openaccess.thecvf.com/content/CVPR2025/html/Guo_ ArticulatedGS_Self-supervised_Digital_Twin_Modeling_of_ Articulated_Objects_using_3D_CVPR_2025_paper.html [4]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,” in Computer Vision – ECCV 2020, 2020, p. 405–421. [Online]. Available: https://doi.org/10.1007/978-3-030-58452-8_24 [5]T. Müller, A. Evans, C. Schied, and A. Keller, “Instant Neural Graphics Primitives with a Multiresolution Hash Encoding,” ACM Transactions on Graphics, vol. 41, no. 4, p. 1–15, 2022, article 102. [Online]. Available: https://doi.org/10.1145/3528223.3530127 PREPRINT13 [6]B. Kerbl, G. Kopanas, T. Leimkühler, and G. Drettakis, “3D Gaussian Splatting for Real-Time Radiance Field Rendering,” ACM Transactions on Graphics, vol. 42, no. 4, p. 1–14, 2023. [Online]. Available: https://doi.org/10.1145/3592433 [7]Y.-H. Huang, Y.-T. Sun, Z. Yang, X. Lyu, Y.-P. Cao, and X. Qi, “SC- GS: Sparse-Controlled Gaussian Splatting for Editable Dynamic Scenes,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2024, p. 4220–4230. [Online].Available:https://openaccess.thecvf.com/content/ CVPR2024/html/Huang_SC-GS_Sparse-Controlled_Gaussian_ Splatting_for_Editable_Dynamic_Scenes_CVPR_2024_paper.html [8]J. Lin, Z. Li, X. Tang, J. Liu, S. Liu, J. Liu, Y. Lu, X.Wu,S.Xu,Y.Yan,andW.Yang,“VastGaussian: Vast 3D Gaussians for Large Scene Reconstruction,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2024, p. 5166–5175. [Online]. Available:https://openaccess.thecvf.com/content/CVPR2024/ html/Lin_VastGaussian_Vast_3D_Gaussians_for_Large_Scene_ Reconstruction_CVPR_2024_paper.html [9]X. Du, Y. Wang, K. Zhan, and X. Yu, “Mobile-GS: Real-Time Gaussian Splatting for Mobile Devices,” 2026. [Online]. Available: https://arxiv.org/abs/2603.11531 [10] H. Zhu, X. Huang, 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 on Mobile Devices,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2026, p. 25 979–25 989. [Online]. Available: https://openaccess.thecvf.com/content/CVPR2026/html/Zhu_ Seele_A_Unified_Acceleration_Framework_for_Real-Time_ Gaussian_Splatting_on_CVPR_2026_paper.html [11] Z. Ye, Y. Fu, J. Zhang, L. Li, Y. Zhang, S. Li, C. Wan, C. Wan, C. Li, S. Prathipati, and Y. C. Lin, “Gaussian Blending Unit: An Edge GPU Plug-In for Real-Time Gaussian-Based Rendering in AR/VR,” in 2025 IEEE International Symposium on High Performance Computer Architecture (HPCA), 2025. [Online]. Available: https://arxiv.org/abs/2503.23625 [12] H. Wang, Z. Zhu, T. Zhao, Y. Xiang, Z. Wang, J. Yu, H. Yang, Y. Xie, and Y. Wang, “REACT3D: Real-time Edge Accelerator for Incremental Training in 3D Gaussian Splatting based SLAM Systems,” in Proceedings of the 58th IEEE/ACM International Symposium on Microarchitecture (MICRO), 2025, p. 1852–1866. [Online]. Available: https://doi.org/10.1145/3725843.3756109 [13] G. Feng, S. Chen, R. Fu, Z. Liao, Y. Wang, T. Liu, B. Hu, L. Xu, Z. Pei, H. Li, X. Li, N. Sun, X. Zhang, and B. Dai, “FlashGS: Efficient 3D Gaussian Splatting for Large-Scale and High-Resolution Rendering,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2025, p. 26 652–26 662. [Online]. Available: https://openaccess.thecvf.com/content/CVPR2025/html/Feng_ FlashGS_Efficient_3D_Gaussian_Splatting_for_Large-scale_and_ High-resolution_Rendering_CVPR_2025_paper.html [14] 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, p. 497–511. [Online]. Available: https://doi.org/10.1145/3620666.3651385 [15] H. Gui, L. Hu, R. Chen, M. Huang, Y. Yin, J. Yang, Y. Wu, C. Liu, Z. Sun, X. Zhang, and K. Zhan, “Balanced 3DGS: Gaussian-wise Parallelism Rendering with Fine-Grained Tiling,” 2025. [Online]. Available: https://arxiv.org/abs/2412.17378 [16] D. Paj ̨ak, M. Bisson, and R. Lima, “HiGS: A Hierarchical Rendering Architecture for Real-Time 3D Gaussian Splatting,” 2026. [Online]. Available: https://arxiv.org/abs/2606.00352 [17] S. Durvasula, A. Zhao, F. Chen, R. Liang, P. K. Sanjaya, and N. Vijaykumar, “DISTWAR: Fast Differentiable Rendering on Raster-based Rendering Pipelines,” 2024. [Online]. Available: https://arxiv.org/abs/2401.05345 [18] H. Zhao, X. Min, X. Liu, M. Gong, Y. Li, A. Li, S. Xie, J. Li, and A. Panda, “CLM: Removing the GPU Memory Barrier for 3D Gaussian Splatting,” 2025. [Online]. Available: https://arxiv.org/abs/2511.04951 [19] D. Lee, D. Jeong, J. W. Lee, and H. Yoon, “GS-Scale: Unlocking Large-Scale 3D Gaussian Splatting Training via Host Offloading,” 2025. [Online]. Available: https://arxiv.org/abs/2509.15645 [20] H. He, G. Li, F. Liu, L. Jiang, X. Liang, and Z. Song, “GSArch: Breaking Memory Barriers in 3D Gaussian Splatting Training via Architectural Support,” in 2025 IEEE International Symposium on High Performance Computer Architecture (HPCA), 2025, p. 366–379. [Online]. Available: https://doi.org/10.1109/HPCA61900.2025. 00037 [21] 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,” ACM TransactionsonGraphics,2024.[Online].Available:https: //arxiv.org/abs/2406.12080 [22] J. C. Lee, D. Rho, X. Sun, J. H. Ko, and E. Park, “Compact 3D Gaussian Representation for Radiance Field,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2024, p. 21 719–21 728. [Online]. Available:https://openaccess.thecvf.com/content/CVPR2024/ html/Lee_Compact_3D_Gaussian_Representation_for_Radiance_ Field_CVPR_2024_paper.html [23] Z.Fan,K.Wang,K.Wen,Z.Zhu,D.Xu,and Z.Wang,“LightGaussian:Unbounded3DGaussian Compressionwith15xReductionand200+FPS,” inAdvancesinNeuralInformationProcessingSystems, vol.37,2024,p.140 138–140 158.[Online].Available: https://proceedings.neurips.c/paper_files/paper/2024/hash/ 4e5a019f664e2d777a3d41ce2c1187f-Abstract-Conference.html [24] Y. Chen, Q. Wu, W. Lin, M. Harandi, and J. Cai, “HAC: Hash-GridAssistedContextfor3DGaussianSplatting Compression,”inComputerVision–ECCV2024,2024. [Online]. Available: https://w.ecva.net/papers/eccv_2024/ papers_ECCV/html/540_ECCV_2024_paper.php [25] S. Li, B. Keller, Y. C. Lin, and B. Khailany, “GauRast: Enhancing GPU Triangle Rasterizers to Accelerate 3D Gaussian Splatting,” 2025. [Online]. Available: https://arxiv.org/abs/2503.16681 [26] M. T. Bagdasarian, P. Knoll, Y. Li, F. Barthel, A. Hilsmann, P. Eisert, and W. Morgenstern, “3DGS.zip: A Survey on 3D Gaussian Splatting Compression Methods,” Computer Graphics Forum, vol. 44, no. 2, p. e70078, 2025. [Online]. Available: https://doi.org/10.1111/cgf.70078 [27] M. S. Ali, C. Zhang, M. Cagnazzo, G. Valenzise, E. Tartaglione, and S.-H. Bae, “Compression in 3D Gaussian Splatting: A Survey of Methods, Trends, and Future Directions,” 2025. [Online]. Available: https://arxiv.org/abs/2502.19457 [28] S. Youn, S. Lee, G. Kim, W. Kwon, S.-H. Bae, and J. Oh, “SUCCESS-GS: Survey of Compactness and Compression for Efficient Static and Dynamic Gaussian Splatting,” 2025. [Online]. Available: https://arxiv.org/abs/2512.07197 [29] F. Tosi, Y. Zhang, Z. Gong, E. Sandström, S. Mattoccia, M. R. Oswald, and M. Poggi, “How NeRFs and 3D Gaussian Splatting Are Reshaping SLAM: A Survey,” 2024. [Online]. Available: https://arxiv.org/abs/2402.13255 [30] S. Zhu, G. Wang, X. Kong, D. Kong, and H. Wang, “3D Gaussian Splatting in Robotics: A Survey,” 2024. [Online]. Available: https://arxiv.org/abs/2410.12262 [31] S. Qiu, B. Xie, Q. Liu, and P.-A. Heng, “Advancing Extended Reality with 3D Gaussian Splatting: Innovations and Prospects,” in 2025 IEEE International Conference on Artificial Intelligence and eXtended and Virtual Reality (AIxVR), 2025. [Online]. Available: https://arxiv.org/abs/2412.06257 [32] J. Peng, X. Mo, C. Nian, and C. Zhang, “Review on Hardware Accelerator for 3D Gaussian Splatting,” Microelectronics & Computer, vol. 42, no. 10, p. 66–77, 2025. [Online]. Available: https://doi.org/10.19304/J.ISSN1000-7180.2025.0584 [33] M. Pei, G. Li, J. Si, Z. Zhu, Z. Mo, P. Wang, Z. Song, X. Liang, and J. Cheng, “GCC: A 3DGS Inference Architecture with Gaussian-Wise and Cross-Stage Conditional Processing,” in Proceedings of the 58th IEEE/ACM International Symposium on Microarchitecture (MICRO), 2025. [Online]. Available: https: //arxiv.org/abs/2507.15300 [34] J. Lee, Y. Lee, Y. Kwon, and M. Rhu, “Characterization and Analysis of the 3D Gaussian Splatting Rendering Pipeline,” IEEE Computer Architecture Letters, vol. 24, no. 1, p. 13–16, 2025. [Online]. Available: https://doi.org/10.1109/LCA.2024.3504579 [35] M. Pei, G. Li, Z. Zhu, S. Wang, J. Si, Z. Song, Y. Feng, F. Liu, X. Liang, and J. Cheng, “DeGS: A Scalable 3DGS Architecture via Decoupled Workload Parsing and Reorganization,” 2026. [Online]. Available: https://arxiv.org/abs/2608.02099 [36] C. Oh, S. Oh, J. Hwang, Y. Kim, H. Sharma, and J. Park, “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 PREPRINT14 Languages and Operating Systems (ASPLOS), 2026. [Online]. Available: https://arxiv.org/abs/2511.12930 [37] P. Papantonakis, G. Kopanas, B. Kerbl, A. Lanvin, and G. Drettakis, “Reducing the Memory Footprint of 3D Gaussian Splatting,” Proceedings of the ACM on Computer Graphics and Interactive Techniques, vol. 7, no. 1, p. 16:1–16:17, 2024. [Online]. Available: https://doi.org/10.1145/3651282 [38] M. S. Ali, M. Qamar, S.-H. Bae, and E. Tartaglione, “Trimming the Fat: Efficient Compression of 3D Gaussian Splats through Pruning,” in Proceedings of the British Machine Vision Conference (BMVC), 2024. [Online]. Available: https://papers.bmvc2024.org/ 0358.pdf [39] J. Chen, Y. Chen, Y. Zou, Y. Huang, P. Wang, Y. Liu, Y. Sun, and W. Wang, “MEGS2: Memory-Efficient Gaussian Splatting via Spherical Gaussians and Unified Pruning,” in International Conference on Learning Representations (ICLR), 2026. [Online]. Available: https://arxiv.org/abs/2509.07021 [40] A. Hanson, A. Tu, V. Singla, M. Jayawardhana, M. Zwicker, andT.Goldstein,“PUP3D-GS:PrincipledUncertainty Pruningfor3DGaussianSplatting,”inProceedings oftheIEEE/CVFConferenceonComputerVisionand Pattern Recognition (CVPR), 2025, p. 5949–5958. [Online]. Available:https://openaccess.thecvf.com/content/CVPR2025/ html/Hanson_PUP_3D-GS_Principled_Uncertainty_Pruning_ for_3D_Gaussian_Splatting_CVPR_2025_paper.html [41] A. Hanson, A. Tu, G. Lin, V. Singla, M. Zwicker, and T.Goldstein,“Speedy-Splat:Fast3DGaussianSplatting with Sparse Pixels and Sparse Primitives,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition(CVPR),2025,p.21 537–21 546.[Online]. Available:https://openaccess.thecvf.com/content/CVPR2025/ html/Hanson_Speedy-Splat_Fast_3D_Gaussian_Splatting_with_ Sparse_Pixels_and_Sparse_Primitives_CVPR_2025_paper.html [42] W. Mousa and A. Maalouf, “Provable Pruning for Efficient 3D Gaussian Splatting via Coresets,” 2026. [Online]. Available: https://arxiv.org/abs/2607.02721 [43] S.Niedermayr,J.Stumpfegger,andR.Westermann, “Compressed 3D Gaussian Splatting for Accelerated Novel View Synthesis,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2024. [Online]. Available:https://openaccess.thecvf.com/content/CVPR2024/ html/Niedermayr_Compressed_3D_Gaussian_Splatting_for_ Accelerated_Novel_View_Synthesis_CVPR_2024_paper.html [44] S. Lee, F. Shu, Y. Sanchez, T. Schierl, and C. Hellge, “Compression of 3D Gaussian Splatting with Optimized Feature Planes and Standard Video Codecs,” in Proceedings oftheIEEE/CVFInternationalConferenceonComputer Vision (ICCV), 2025, p. 25 496–25 505. [Online]. Available: https://openaccess.thecvf.com/content/ICCV2025/html/Lee_ Compression_of_3D_Gaussian_Splatting_with_Optimized_ Feature_Planes_and_ICCV_2025_paper.html [45] Y. Chen, Q. Wu, W. Lin, M. Harandi, and J. Cai, “HAC++: Towards 100X Compression of 3D Gaussian Splatting,” IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 47, no. 11, p. 10 210–10 226, 2025. [Online]. Available: https: //doi.org/10.1109/TPAMI.2025.3594066 [46] T. Wang, Z. Yu, and Y. Xu, “TC-GS: Tri-plane Based Compression for 3D Gaussian Splatting,” in IEEE International Conference on Multimedia and Expo (ICME), 2025. [Online]. Available: https://arxiv.org/abs/2503.20221 [47] Z. Tang, C. Feng, X. Cheng, W. Yu, J. Zhang, Y. Liu, X.-X. Long, W. Wang, and L. Yuan, “NeuralGS: Bridging Neural Fields and 3D Gaussian Splatting for Compact 3D Representations,” Proceedings of the AAAI Conference on Artificial Intelligence, vol. 40, no. 11, p. 9493–9501, 2026. [Online]. Available: https://doi.org/10.1609/aaai.v40i11.37910 [48] X. Du, Y. Wang, H. Li, B. Wang, X. Sun, and X. Yu, “Monte Carlo Energy Aggregation for Mobile 3D Gaussian Splatting,” in Computer Vision – ECCV 2026, 2026. [Online]. Available: https://arxiv.org/abs/2606.30017 [49] Y. Seo, Y. S. Choi, H. Son, and Y. Uh, “FLoD: Integrating Flexible Level of Detail into 3D Gaussian Splatting for Customizable Rendering,” ACM Transactions on Graphics, vol. 44, no. 4, p. 1–16, 2025. [Online]. Available: https://doi.org/10.1145/3731430 [50] Z. Yan, W. F. Low, Y. Chen, and G. H. Lee, “Multi-Scale 3DGaussianSplattingforAnti-AliasedRendering,”in Proceedings of the IEEE/CVF Conference on Computer Vision andPatternRecognition(CVPR),2024,p.20 923–20 931. [Online].Available:https://openaccess.thecvf.com/content/ CVPR2024/html/Yan_Multi-Scale_3D_Gaussian_Splatting_for_ Anti-Aliased_Rendering_CVPR_2024_paper.html [51] 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, p. 669–682. [Online]. Available: https://doi.org/10.1145/3669940.3707227 [52] L. Diels, M. Vlaminck, W. Philips, and H. Luong, “Fast 3D Gaus- sian Splatting Rendering via Easily Integrable Improvements,” IEEE Signal Processing Letters, vol. 32, p. 381–385, 2025. [Online]. Available: https://doi.org/10.1109/LSP.2024.3521379 [53] L. Radl, M. Steiner, M. Parger, A. Weinrauch, B. Kerbl, and M. Steinberger, “StopThePop: Sorted Gaussian Splatting for View-Consistent Real-Time Rendering,” ACM Transactions on Graphics, vol. 43, no. 4, p. 1–17, 2024. [Online]. Available: https://doi.org/10.1145/3658187 [54] Z. Huang, C.-Y. Wu, Y. Guo, X. Huang, and L. Ren, “3DGEER: 3D Gaussian Rendering Made Exact and Efficient for Generic Cameras,” in International Conference on Learning Representations (ICLR), 2026. [Online]. Available: https://arxiv.org/abs/2505. 24053 [55] F. Hahlbohm, F. Friederichs, T. Weyrich, L. Franke, M. Kappel, S. Castillo, M. Stamminger, M. Eisemann, and M. Magnor, “Efficient Perspective-Correct 3D Gaussian Splatting Using Hybrid Transparency,” Computer Graphics Forum, vol. 44, no. 2, p. e70014, 2025. [Online]. Available: https://doi.org/10.1111/cgf. 70014 [56] Q. Hou, R. Rauwendaal, Z. Li, H. Le, F. Farhadzadeh, F. Porikli, A. Bourd, and A. Said, “Sort-Free Gaussian Splatting via Weighted Sum Rendering,” in International Conference on Learning Representations (ICLR), 2025. [Online]. Available: https://openreview.net/forum?id=y8uPsxR8PN [57] S. Kheradmand, D. Vicini, G. Kopanas, D. Lagun, K. M. Yi, M. Matthews, and A. Tagliasacchi, “StochasticSplats: Stochastic Rasterization for Sorting-Free 3D Gaussian Splatting,” in Proceed- ings of the IEEE/CVF International Conference on Computer Vision (ICCV), 2025, p. 26 326–26 335. [58] A. Tu, H. Ying, A. Hanson, Y. Lee, T. Goldstein, and M. Zwicker, “SpeeDe3DGS: Speedy Deformable 3D Gaussian Splatting with Temporal Pruning and Motion Grouping,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2026, p. 26 083–26 093. [Online]. Available: https://arxiv.org/abs/2506.07917 [59] Y. Zhan, H. Wang, T. Shao, and K. Zhou, “High-Fidelity Mobile Avatars with Pruned Local Blendshapes,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2026. [Online]. Available: https://arxiv.org/abs/2605. 01854 [60] L. Li, J. Qin, J. Peng, Z. Wan, H. Qu, Y. Han, P. Zheng, H. Zhang, Y. Cao, T. Chen, and Y. K. Zhao, “RTGS: Real-Time 3D Gaussian Splatting SLAM via Multi-Level Redundancy Reduction,” in Proceedings of the 58th IEEE/ACM International Symposium on Microarchitecture (MICRO), 2025. [Online]. Available: https://arxiv.org/abs/2510.06644 [61] X. Wang, R. Yi, and L. Ma, “AdR-Gaussian: Accelerating Gaussian Splatting with Adaptive Radius,” in SIGGRAPH Asia 2024 Conference Papers, 2024, p. 1–10. [Online]. Available: https://doi.org/10.1145/3680528.3687675 [62] Y. Luo, Y. Gong, Y. Gao, J. Zhao, X. Zhang, and H. Liu, “Local-GS:Accelerating3DGaussianSplattingviaTile- Local Warp Coherence,” 2026. [Online]. Available: https: //arxiv.org/abs/2606.16566 [63] S. S. Mallick, R. Goel, B. Kerbl, M. Steinberger, F. V. Carrasco, and F. de la Torre, “Taming 3DGS: High-Quality Radiance Fields with Limited Resources,” in SIGGRAPH Asia 2024 Conference Papers, 2024, p. 1–11. [Online]. Available: https://doi.org/10.1145/3680528.3687694 [64] F. Hahlbohm, L. Franke, M. Eisemann, and M. Magnor, “Faster- GS: Analyzing and Improving Gaussian Splatting Optimization,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2026, p. 18 946–18 957. [Online]. Available:https://openaccess.thecvf.com/content/CVPR2026/ html/Hahlbohm_Faster-GS_Analyzing_and_Improving_ Gaussian_Splatting_Optimization_CVPR_2026_paper.html PREPRINT15 [65] V. Ye, R. Li, J. Kerr, M. Turkulainen, B. Yi, Z. Pan, O. Seiskari, J. Ye, J. Hu, M. Tancik, and A. Kanazawa, “gsplat: An Open-Source Library for Gaussian Splatting,” Journal of Machine Learning Research, vol. 26, p. 1–17, 2025. [Online]. Available: https://w.jmlr.org/papers/v26/24-1476.html [66] C. Zhong, L. Shi, H. Chen, T. Sun, H. Zhao, B. Yuan, and C. Li, “TideGS: Scalable Training of Over One Billion 3D Gaussian Splatting Primitives via Out-of-Core Optimization,” in International Conference on Machine Learning (ICML), 2026. [Online]. Available: https://arxiv.org/abs/2605.20150 [67] H. Zhao, H. Weng, D. Lu, A. Li, J. Li, A. Panda, and S. Xie, “On Scaling Up 3D Gaussian Splatting Training,” in International Conference on Learning Representations (ICLR), 2025. [Online]. Available: https://arxiv.org/abs/2406.18533 [68] W. Jia, Z. Hu, Y. Huang, Y. Gong, S. Kalafatis, Y. Wang, W. Niu, C. Zhang, A. Li, S. Di, Y. Ji, B. Fang, and M. Yin, “Splaxel: Efficient Distributed Training of 3D Gaussian Splatting for Large-scale Scene Reconstruction via Pixel-level Communication,” 2026. [Online]. Available: https://arxiv.org/abs/2606.18588v1 [69] K. Liao, H. Wang, Z. Chen, L. Wang, and Y. Tang, “LiteGS: A High-Performance Framework to Train 3DGS in Subminutes via System and Algorithm Codesign,” 2025. [Online]. Available: https://arxiv.org/abs/2503.01199 [70] S.-H. Hung, T.-Y. Yen, W.-F. Sun, S. See, S.-H. Hung, and H.-K. Chu, “LoBE-GS: Load-Balanced and Efficient 3D Gaussian Splatting for Large-Scale Scene Reconstruction,” 2026. [Online]. Available: https://arxiv.org/abs/2510.01767 [71] H. Zhu, Z. Liu, X. Li, A. Wu, J. Zhao, F. Liu, Y. Gan, J. Leng, and Y. Feng, “Nebula: Infinite-Scale 3D Gaussian Splatting in VR via Collaborative Rendering and Accelerated Stereo Rasterization,” in Proceedings of the 31st ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2 (ASPLOS), 2026, p. 1235–1250. [Online]. Available: https://doi.org/10.1145/3779212.3790190 [72] J. Jo and J. Park, “GS-TG: 3D Gaussian Splatting Accelerator with Tile Grouping for Reducing Redundant Sorting while Preserving Rasterization Efficiency,” in Proceedings of the 62nd ACM/IEEE Design Automation Conference (DAC), 2025, p. 1–7. [Online]. Available: https://arxiv.org/abs/2509.00911 [73] C. Zhang, Y. Feng, J. Zhao, G. Liu, W. Ding, C. Wu, and M. Guo, “STREAMINGGS: Voxel-Based Streaming 3D Gaussian Splatting with Memory Optimization and Architectural Support,” in Proceedings of the 62nd ACM/IEEE Design Automation Conference (DAC), 2025. [Online]. Available: https://arxiv.org/abs/2506. 09070 [74] M. Yang, Y. Wang, C.-P. Lo, X. Zhang, S. Oruganti, and J. P. Kulkarni, “GSAcc: Accelerate 3D Gaussian Splatting via Depth Speculation and Gaussian-centric Rasterization,” in Proceedings of the 62nd ACM/IEEE Design Automation Conference (DAC), 2025, p. 1–7. [Online]. Available: https: //doi.org/10.1109/DAC63849.2025.11133032 [75] L. Wei, J. Tang, F. Fei, B. Shi, R. Wang, and M. Li, “No Redundancy, No Stall: Lightweight Streaming 3D Gaussian Splatting for Real-time Rendering,” 2025. [Online]. Available: https://arxiv.org/abs/2507.21572 [76] Y. Wang, M. Yang, C. pu Lo, and J. P. Kulkarni, “Vorion: A RISC-V GPU with Hardware-Accelerated 3D Gaussian Rendering and Training,” 2025. [Online]. Available: https: //arxiv.org/abs/2511.16831 [77] W. Ou, Z. Wu, Y. Zhang, D. Wu, F. Z. Hong, and C. P. Yue, “FLICKER: A Fine-Grained Contribution-Aware Accelerator for Real-Time 3D Gaussian Splatting,” in Design, Automation and Test in Europe Conference (DATE), 2026. [Online]. Available: https://arxiv.org/abs/2603.01158 [78] F.-C. Chang and T.-S. Chang, “A 129 FPS Full HD Real-Time Accelerator for 3D Gaussian Splatting,” IEEE Transactions on Visualization and Computer Graphics, vol. 32, no. 7, p. 6537–6547, 2026. [Online]. Available: https://doi.org/10.1109/TVCG.2026. 3683714 [79] W.-H. Huang, C.-J. Shih, J.-W. Su, S. W. Wang, V. Garg, Y. Kong, J.-C. Tien, N. Li, A. Raychowdhury, M.-F. Chang, Y. C. Lin, and S. Yu, “3DGauCIM: Accelerating Static/Dynamic 3D Gaussian Splatting via Digital CIM for High Frame Rate Real-Time Edge Rendering,” ACM Transactions on Design Automation of Electronic Systems, vol. 31, no. 4, p. Article 81, 2026. [Online]. Available: https://arxiv.org/abs/2507.19133 [80] S. R. Bulò, N. Bartolovic, L. Porzi, and P. Kontschieder, “Hardware- Rasterized Ray-Based Gaussian Splatting,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2025, p. 485–494. [81] Y.YuanandQ.He,“EfficientDifferentiableHardware Rasterization for 3D Gaussian Splatting,” 2025. [Online]. Available: https://arxiv.org/abs/2505.18764 [82] J. Lee, J. Kim, J. Park, and J. Sim, “VR-Pipe: Streamlining HardwareGraphicsPipelineforVolumeRendering,”in IEEE International Symposium on High Performance Computer Architecture (HPCA), 2025, p. 217–230. [Online]. Available: https://doi.org/10.1109/HPCA61900.2025.00027 [83] H. Li, Y. Liang, F. Liu, B. Zhu, Z. Wang, Y. Feng, L. Lu, L. Jiang, and H. Guan, “ORANGE: Exploring Ockham’s Razor for Neural Rendering by Accelerating 3DGS on NPUs with GEMM-Friendly Blending and Balanced Workloads,” in 2026 IEEE International Symposium on High Performance Computer Architecture (HPCA), 2026. [Online]. Available: https: //ieeexplore.ieee.org/document/11408575/ [84] R. Wen, Z. Yue, T. Liu, X. Song, J. Li, D. Huang, J. Guo, X. Hu, Z. Du, Q. Guo, and T. Chen, “Cambricon-GS: An Accelerator for 3D Gaussian Splatting Training with Gaussian-Pixel Hybrid Parallelism,” in IEEE International Symposium on High-Performance Computer Architecture (HPCA), 2026, p. 1–14. [Online]. Available: https://doi.org/10.1109/HPCA68181.2026.11408562 [85] L. Wu, H. Zhu, S. He, J. Zheng, C. Chen, and X. Zeng, “GauSPU: 3D Gaussian Splatting Processor for Real-Time SLAM Systems,” in Proceedings of the 57th IEEE/ACM International Symposium on Microarchitecture (MICRO), 2024, p. 1562–1573. [Online]. Available: https://ieeexplore.ieee.org/document/10764611 [86] H. Kweon, J. Kim, and J. Park, “BOA-3DGS: Backward-Striding Optimized Accelerator for Reduced Memory Contention in 3D Gaussian Splatting Training,” in Asia and South Pacific Design Au- tomation Conference (ASP-DAC), 2026, p. 341–347. [Online]. Avail- able: https://doi.org/10.1109/ASP-DAC66049.2026.11420496 [87] X. Huang, H. Zhu, T. Ma, Y. Xiong, F. Liu, Z. He, Y. Gan, Z. Liu, J. Leng, Y. Feng, and M. Guo, “Splatonic: Architecture Support for 3D Gaussian Splatting SLAM via Sparse Processing,” in 2026 IEEE International Symposium on High Performance Computer Architecture (HPCA), 2026. [Online]. Available: https://arxiv.org/abs/2511.18755 [88] J. Park, S. Kim, S. Song, W. Park, J. Ryu, and H.-J. Yoo, “Garnet: A 10.1 mJ/iter 3DGS Modeling Accelerator with Gradient Similarity-Based Skipping and Unified Volume Rendering Core,” in IEEE Asian Solid-State Circuits Conference (A-SSCC), 2025, p. 34–36. [Online]. Available: https://epapers2.org/asscc2025/ESR/ paper_details.php?paper_id=4292 [89] H. Lee, W. Park, S. An, J. Ryu, and H.-J. Yoo, “A Real-time 4.31 mJ/Frame Neural-3DGS Processor with Voxel Similarity Memory Management and Opacity-based Sparsity Generation,” in IEEE International Symposium on Circuits and Systems (ISCAS), 2025, p. 1–5. [90] S. Song, S. Kim, W. Park, J. Park, S. An, G. Park, M. Kim, and H.-J. Yoo, “IRIS: An Energy-Efficient Spatial Computing SoC for Real-Time Interactive Rendering and Modeling With Surface-Aware 3-D Gaussian Splatting,” IEEE Journal of Solid-State Circuits, vol. 61, no. 1, p. 183–196, 2026. [Online]. Available: https://doi.org/10.1109/JSSC.2025.3613707 [91] Y. Feng, W. Lin, Y. Cheng, Z. Liu, J. Leng, M. Guo, C. Chen, S. Sun, and Y. Zhu, “Lumina: Real-Time Mobile Neural Rendering by Exploiting Computational Redundancy,” 2025. [Online]. Available: https://arxiv.org/abs/2506.05682 [92] H. Joo, S. Kim, J. Park, J. Ryu, and H.-J. Yoo, “A 51.2 fps Real-Time 3DGS-SLAM Accelerator using Diagonal Feeding with Symmetric Alpha Reuse and Voxel-based 3D Gaussian Cache Management,” in IEEE International Symposium on Circuits and Systems (ISCAS), 2025, p. 1–5. PREPRINT16 APPENDIX A SURVEY CORPUS CONSTRUCTION The survey covers public research on efficient 3D Gaussian splatting. The literature search was frozen on August 20, 2026. The retained corpus draws primary records from IEEE Xplore, the ACM Digital Library, CVF Open Access, OpenReview, arXiv, and official proceedings, journal, supplementary, and project pages. Covered venue families include CVPR, ICCV, ECCV, SIGGRAPH, TOG, NeurIPS, ICLR, ASPLOS, HPCA, MICRO, DAC, DATE, and ICCAD. Search concepts combine “3D Gaussian splatting” or “Gaussian splatting” with terms for compression, pruning, level of detail, culling, rasterization, sorting, GPU execution, memory or communication, accelerators, training, dynamic scenes, SLAM, and mobile or edge systems. Candidates were screened for a direct connection to 3DGS system efficiency. We include algorithmic work only for material effects on stored Gaussian data, Gaussians in rendering memory or selected for a frame, per-frame rendering work, data movement, cached order or image data, gradients and optimizer arrays, or an explicitly measured system- efficiency outcome. GPU-runtime and architecture studies are included when implementing or evaluating a stage on the rendering, training, or online-update path. Pure application work without an efficiency implication is excluded, as are studies concerned only with visual quality, reconstruction accuracy, or an application result without a relevant system cost. We also exclude adjacent non-3DGS methods, duplicate versions without additional system evidence, and records for which no primary full text or official supplement can be verified. When multiple versions exist, the retained record is the most complete verifiable version and preserves the scope of its measurements. Screening examines titles and abstracts, then original papers and supplements. Narrative and quantitative inclusion differ. Quantitative records must identify the affected workload or resource quantity, comparison baseline, input and configuration, quality settings, and timed operations. Missing fields are recorded as unavailable. APPENDIX B EVALUATION EVIDENCE COVERAGE Fig. 9 audits quantitative evidence available in an audited subset of the works discussed in Sections 3–5. Quality and end-to-end performance are jointly reported for 98.3% of 59 applicable works. Coverage falls to 69.5% when workload evidence is also required and to 54.2% when stage timing is required. The audit is limited to evidence availability. 020406080100 Applicable-paper coverage (%) Training / online updates Power / energy Memory / traffic End-to-end latency / FPS Stage timing / breakdown Workload counter Representation size / Gaussian count Quality 77.5% 85.0% 64.5% 98.4% 69.4% 69.4% 100.0% 100.0% (a) Metric coverage Paper-reportedSurvey-reproducedUnavailable 020406080100 Applicable-paper co-reporting (%) D. B + Memory / traffic C. B + Stage timing B. A + Workload A. Quality + E2E 57.6% 54.2% 69.5% 98.3% (b) Joint evidence prerequisites Fig. 9. Evidence coverage in the audited subset. Quality and end-to-end performance are commonly reported together. Workload and stage timing are less often jointly available. APPENDIX C REPRODUCIBILITY PROTOCOL C.1 Cross-Paper Evidence Admission Figs. 4 and 6(d) use within-source comparisons. Cross-paper normalization is not applied. A quantitative point is admitted when the source identifies the affected workload or resource quantity, baseline and optimized conditions, input or aggregation scope, quality settings, and operations measured. Reported values, arithmetic derived from reported table entries, and survey reproductions are recorded separately. Missing workload counters remain unavailable. Admission is independent of speedup direction, and the data support neither cross-paper ranking nor regression. Fig. 4 covers Reducing Memory Footprint, Compact3DGS, LightGaussian, PUP 3D-GS and PUP+Vectree, HAC++, Flux- GS, Mobile-GS, Speedy-Splat, FLoD, Hierarchical 3DGS, and gsplat, AdRGS, and FlashGS configurations. AdRGS denotes the AdRGS-AABB configuration of AdR-Gaussian [61], using FPS and association counts from FlashGS [13] Tables 1 and 3, PREPRINT17 respectively. Each point retains provenance, reported or derived status, baseline, dataset or scene, aggregation, platform, backend, resolution, timing scope, and quality context. Fig. 6(d) admits FlashGS, HiGS, Local-GS, gsplat, CLM, and Faster- GS under the same rule. Aggregates follow point-level admission, retaining matched operations and available quality differences. C.2 Controlled GPU Profiling Measurements use an NVIDIA RTX 3090. The controlled tile experiment underlying Fig. 6(a)–(c) collects workload counts from the materialized Gaussian–tile and per-pixel candidate lists. Each scene–view result is normalized only to its counterpart at the reference tile size. Output consistency and workload-count invariants are checked before timing collection. Fig. 7 reports descriptive workload–stage relationships within a fixed measurement population on the same GPU; these do not establish cross-GPU or cross-backend generalization. Fig. 8 compares backends with the model and views held fixed. Complete forward latency is collected without profiler attachment; Nsight Compute replay separately measures kernel composition and DRAM traffic. Counts describe implementation-specific workloads because culling and intersection semantics differ. C.3 Reproducibility Boundary The evidence package includes figure inputs, provenance, collection and plotting scripts, and measurement configurations. Records distinguish reported, derived, and survey-measured values. Offline plotting requires no GPU or external survey checkout. Instrumentation counts post-projection pair-producing Gaussians as N active and the materialized list length as N pair . GPU recollection requires the documented inputs, builds, and profiler settings and covers measured calls, not complete training procedures. C.4 Open-Source Artifact GSPROF and its paper evidence package are available at https://github.com/HAPPYPMN/gsprof/tree/v0.4.1. The toolkit is MIT-licensed; third-party components retain their licenses. APPENDIX D SUPPLEMENTARY BACKEND MEASUREMENTS Table 4 provides capacity and reconstruction-quality checks for the matched-backend comparison in Fig. 8. Peak allocated memory includes the representation, constructed buffers, and temporary storage. PSNR, SSIM, and LPIPS evaluate each backend against the same ground-truth images. Each reported difference is the maximum over measured views of the absolute per-view score difference from Graphdeco. TABLE 4 Backend Memory and Reconstruction Quality Backend Peak memory (GiB) median [min–max] Max. absolute score difference PSNRSSIMLPIPS Graphdeco1.92 [1.88, 1.94]0.0000.00000.0000 gsplat0.97 [0.81, 0.99]0.0360.00050.0003 FlashGS0.94 [0.94, 0.94]0.0760.00280.0043 StopThePop1.96 [1.92, 1.98]0.0010.00000.0000 Speedy-Splat1.79 [1.75, 1.79]0.0010.00000.0000 Faster-GS1.95 [1.79, 1.96]0.1060.00450.0025 Peak memory is summarized over measured views. Score differences use Graphdeco as the reference.