SLTarch: Scalable Point-Based Neural Rendering

• SLTarch is an algorithm-architecture framework that integrates a subtree-based LoD search with divergence-free splatting for scalable point-based neural rendering.
• It employs a dedicated LTcore and SLTree structure to balance workload and streaming memory access, achieving up to 3.9× speedup and 98% energy savings versus mobile GPUs.
• The novel SPcore uses 2×2 group-level splatting to mitigate warp divergence, preserving near-original image quality while reducing GPU utilization issues.

Searching arXiv for the exact term and closely related rendering/accelerator work to ground the article in current literature. SLTarch is an algorithm-architecture co-designed framework for scalable point-based neural rendering (PBNR), proposed to address the two stages that dominate large-scene hierarchical Gaussian rendering on mobile and edge devices: level-of-detail (LoD) search and splatting. In the formulation introduced by “SLTarch: Towards Scalable Point-Based Neural Rendering by Taming Workload Imbalance and Memory Irregularity,” SLTarch combines a subtree-based representation of the LoD hierarchy, a dedicated LoD-search engine, a divergence-free splatting algorithm, and a lightweight splatting-side hardware augmentation. The framework is positioned around real-time rendering of large scenes, and the reported headline results are a 3.9× speedup and 98% energy savings relative to a mobile GPU, plus 1.8× speedup with 54% energy savings relative to existing accelerator designs (Li et al., 29 Jul 2025).

1. Definition and system scope

SLTarch targets large-scene, hierarchical Gaussian-based neural rendering, including HierarchicalGS-style pipelines, where rendering requires first selecting Gaussian primitives from a hierarchical LoD tree and then splatting the selected Gaussians to the image plane. The paper argues that prior accelerator work had concentrated mostly on splatting, whereas scalable PBNR is increasingly limited by LoD traversal itself. In the reported measurements, LoD search can consume up to 70% of total execution time, and LoD search + splatting account for 85% on average (Li et al., 29 Jul 2025).

At the architectural level, SLTarch consists of four named elements.

Component	Function	Key property
SLTree	Transforms the original LoD tree into bounded-size subtrees	Parallelizable traversal and streaming access
LTcore	Dedicated hardware for LoD search over SLTree	Dynamic subtree scheduling and cache-resident traversal
Divergence-free splatting	Replaces per-pixel divergence with group-level decisions	Uses $2 \times 2$ pixel groups
SPcore	Hardware support for the new splatting method	Small augmentation to existing PBNR accelerators

This decomposition is central to the paper’s argument. SLTarch is not presented as a splatting-only accelerator, nor as a tree-only data structure. It is a coupled algorithm-hardware system in which the data structure regularizes irregular work, and the hardware exploits that regularity (Li et al., 29 Jul 2025).

2. Rendering pipeline and identified bottlenecks

The rendering pipeline assumed by SLTarch has two principal stages. First, the renderer performs LoD search on a hierarchical tree in which each node corresponds to one Gaussian and lower levels contain finer-grained Gaussians. A node is selected when its projected size matches the target LoD; otherwise traversal continues into more detailed descendants. The selected nodes form a cut through the hierarchy. Second, the renderer performs splatting, intersecting selected Gaussians with pixels, sorting by depth, and integrating them into each pixel in sorted order (Li et al., 29 Jul 2025).

The paper identifies a distinct hardware pathology in each stage. For LoD search, the underlying tree has unfixed numbers of children, traversal depth is view-dependent, and memory access is scattered. This causes both workload imbalance and irregular DRAM access. In one GPU experiment with 64 threads, the average workload is $4.1 \times 10^4$ visited nodes with standard deviation $3.1 \times 10^4$, indicating severe imbalance. The paper therefore treats LoD traversal as a systems problem of scheduling and locality rather than simply a geometric query problem (Li et al., 29 Jul 2025).

For splatting, the difficulty is warp divergence. If one thread corresponds to one pixel, different pixels within a warp intersect different subsets of Gaussians. Threads that do not participate in a particular Gaussian update are masked out, and the paper reports that GPU utilization in splatting can drop as low as 31%. A common misconception is that more accurate Gaussian-pixel filtering alone solves the splatting problem; SLTarch instead argues that the core issue is sparse, incoherent control flow across neighboring pixels (Li et al., 29 Jul 2025).

This diagnosis yields the paper’s central thesis: scalable PBNR is limited less by arithmetic throughput than by workload imbalance and memory irregularity in LoD search, and by control divergence in splatting. SLTarch is designed to regularize each of these failure modes without changing the semantics of LoD selection.

3. SLTree and LTcore

SLTree is a transformed version of the original LoD tree in which the hierarchy is partitioned offline into subtrees of bounded size. The subtree size limit is denoted $\tau_s$, and the paper’s default setting is $\tau_s = 32$. Subtree boundaries are not tied to tree depth: a subtree may include nodes from one level or multiple levels. The two explicit design goals are parallelizable traversal with balanced work across threads and fully streaming execution, so that off-chip accesses become contiguous and no intermediate write-back is needed (Li et al., 29 Jul 2025).

Construction proceeds in two stages. The initial partitioning uses BFS from the original LoD tree, grouping traversed nodes until the cumulative count exceeds $\tau_s$. Their immediate children become roots of new pending LoD subtrees. A second subtree merging stage greedily combines small sibling subtrees when they share the same parent subtree, each satisfies $s.\mathrm{size()} \le \tau_s/2$, and their combined size does not exceed $\tau_s$. The paper reports that this merging stage materially improves utilization and speed; without subtree merging, LoD-search speedups are 2.3× on small-scale scenes and 5.2× on large-scale scenes, whereas with merging they become 3.6× and 7.8×, respectively (Li et al., 29 Jul 2025).

A crucial point is that SLTree does not change algorithm semantics. The paper states that it produces bit-accurate results for LoD search relative to the canonical LoD tree. This directly addresses a likely misconception that subtree partitioning approximates the traversal. According to the paper, the approximation in SLTarch lies in the splatting stage, not in SLTree-based LoD selection (Li et al., 29 Jul 2025).

The hardware counterpart is LTcore, a dedicated LoD-search engine tailored to SLTree. In the evaluated design, LTcore contains a $2 \times 2$ array of LT units, a subtree queue, a subtree cache, and a double-buffered output buffer, all running at 1 GHz. The queue size is $1 \times 48$ B, the output buffer is 8 KB and double-buffered, and the subtree cache is 4-way associative, $4.1 \times 10^4$0 entries, 128 KB total (Li et al., 29 Jul 2025).

Traversal operates at subtree granularity. LT units pull subtree IDs from a shared queue, process one subtree at a time, and use a small SRAM ring buffer for traversal state. Nodes inside each subtree are stored in depth-first search order, which enables an important optimization: if a node already satisfies the LoD criterion or is outside the frustum, the engine increments the current node index by the node’s remaining subtree size, skipping all descendants without traceback. This is one of the reasons the paper argues that prior kd-tree accelerators such as QuickNN and Crescent are structurally mismatched to LoD search, since their local-stack traceback mechanisms are unnecessary here (Li et al., 29 Jul 2025).

The subtree queue is partitioned into loaded and unloaded segments. LT units only dequeue subtree IDs whose contents are already in the subtree cache, preventing stalls on cache misses. Because traversal is streaming, the paper also notes that once a subtree is evicted it will not be needed again during the same traversal, so cache replacement policy has little impact; the design therefore uses round-robin replacement (Li et al., 29 Jul 2025).

4. Divergence-free splatting and SPcore

The splatting-side innovation in SLTarch is a divergence-free splatting algorithm that replaces per-pixel inclusion decisions with group-level decisions. The image is partitioned into $4.1 \times 10^4$1 pixel groups. For each Gaussian, transparency is evaluated at the center of the pixel group rather than separately for each pixel. If the transparency at that center is below the threshold $4.1 \times 10^4$2, integration is skipped for the whole group; otherwise all four pixels proceed with blending (Li et al., 29 Jul 2025).

This is an approximation, and the paper is explicit about it. The assumption is that adjacent pixels usually have similar transparency values for the same Gaussian. The significance is architectural rather than merely geometric: once the decision is made at the group level, all four pixels in the group follow the same control path, which eliminates the worst intra-group divergence that had reduced GPU utilization to 31% in the baseline setting (Li et al., 29 Jul 2025).

The hardware support for this algorithm is SPcore, a splatting accelerator derived largely from GSCore but with a redesigned splatting unit. The evaluated SPcore contains 4 projection units, 4 sorting units, $4.1 \times 10^4$3 SP units, and a 256 KB double-buffered global buffer, also at 1 GHz. The paper states that projection, duplication, and sorting are largely retained from GSCore and together contribute only about 15% of total time; the main architectural change is the new SP unit (Li et al., 29 Jul 2025).

Each SP unit contains one $4.1 \times 10^4$4-check unit and four blending units. The $4.1 \times 10^4$5-check unit decides whether a Gaussian should be processed for the entire $4.1 \times 10^4$6 pixel group. If the group is rejected, the Gaussian is not sent to the blending units. The paper further notes a microarchitectural detail: instead of evaluating a full exponent during the $4.1 \times 10^4$7-check, SPcore checks the power of the exponent, reducing hardware cost (Li et al., 29 Jul 2025).

The paper also simplifies the projection side by using a basic 3-$4.1 \times 10^4$8 Gaussian-tile intersection test rather than more precise AABB/OBB-style tests. The rationale is that SPcore’s group-level $4.1 \times 10^4$9-check provides the decisive fine-grained filtering, so the front-end test can remain simpler. This suggests a deliberate redistribution of complexity: SLTarch invests hardware where it most reduces divergence rather than where it most refines geometric culling (Li et al., 29 Jul 2025).

5. Quantitative evaluation

The evaluation uses HierarchicalGS and the HierarchicalGS large-scale scene reconstruction dataset, with two scenes, each containing six rendering scenarios. SLTarch is synthesized using Synopsys/Cadence in TSMC 16 nm FinFET. GPU performance and power are measured on a mobile Ampere GPU on Nvidia Orin SoC and scaled to 16 nm using DeepScaleTool. SRAM is generated with Arm Artisan, and DRAM is modeled with Micron 32 Gb LPDDR4, 4 channels (Li et al., 29 Jul 2025).

The reported end-to-end results establish two comparisons. Relative to the mobile GPU baseline, SLTarch achieves 2.2× speedup on small-scale scenes, 3.9× on large-scale scenes, and up to 6.1× maximum speedup. Energy savings relative to the mobile GPU are reported as 98% across both datasets. Relative to existing accelerator designs, the abstract reports 1.8× speedup and 54% energy savings (Li et al., 29 Jul 2025).

The component comparisons are also informative. GPU+GS achieves 1.2× speedup, whereas GPU+LT achieves 2.2×, supporting the paper’s claim that LoD search matters more than splatting-only acceleration in large scenes. The authors also state that full SLTarch outperforms LT+GSCore, indicating that SPcore is not merely a repackaging of existing splatting hardware (Li et al., 29 Jul 2025).

On the memory side, subtree-based LoD search substantially reduces DRAM traffic. Compared with exhaustive-search LoD methods, the proposed LoD search reduces DRAM traffic by 76.5% on small-scale datasets and 69.6% on large-scale datasets. The paper also reports energy ratios that motivate its locality argument: random DRAM versus random SRAM is approximately 25:1, and non-streaming DRAM versus streaming DRAM is approximately 3:1 (Li et al., 29 Jul 2025).

Image quality degradation is deliberately small. For small-scale scenes, PSNR changes from 21.05 to 21.04, SSIM from 0.758 to 0.756, and LPIPS from 0.289 to 0.291. For large-scale scenes, PSNR changes from 23.51 to 23.50, SSIM from 0.784 to 0.782, and LPIPS from 0.316 to 0.318. The paper explicitly attributes this minor degradation mainly to the SPcore splatting approximation, not to SLTree traversal (Li et al., 29 Jul 2025).

Area results reinforce the system argument. Total area is reported as 1.90 mm$3.1 \times 10^4$0, of which LTcore occupies 0.14 mm$3.1 \times 10^4$1 and SPcore 1.76 mm$3.1 \times 10^4$2. Within LTcore, the LT unit array is 0.03 mm$3.1 \times 10^4$3 and the subtree cache 0.10 mm$3.1 \times 10^4$4. The paper describes this as negligible area overhead relative to a typical mobile SoC of over 100 mm$3.1 \times 10^4$5. It also notes that scaled GSCore area is 1.78 mm$3.1 \times 10^4$6, so SLTarch attains similar area with better performance on scalable workloads (Li et al., 29 Jul 2025).

6. Significance, interpretation, and limitations

SLTarch’s main significance lies in reframing scalable PBNR as a problem of balance and locality rather than only one of splatting throughput. The framework argues that, for large scenes, rendering becomes bottlenecked by irregular LoD traversal and sparse control flow. Its response is to impose structure on both: bounded subtrees for balanced, streaming traversal, and $3.1 \times 10^4$7 group-level splatting decisions for coherent execution. This suggests that scalable Gaussian rendering on mobile devices depends as much on data layout and scheduling as on raw arithmetic acceleration (Li et al., 29 Jul 2025).

The work also clarifies several scope boundaries. It is most directly applicable to hierarchical, scalable PBNR pipelines with an explicit LoD tree and Gaussian splatting, such as HierarchicalGS. It is less directly a drop-in solution for non-hierarchical or ray-sampling-based neural rendering. Offline preprocessing is required for SLTree construction, which is natural for static or preprocessed scenes but less obviously suited to rapidly changing hierarchies. The default setting $3.1 \times 10^4$8 also indicates that some design choices are tuned to the evaluated workload and cache organization (Li et al., 29 Jul 2025).

A further limitation is that the divergence-free splatting method is intentionally approximate. It uses $3.1 \times 10^4$9 pixel groups and a group-center transparency check, so exact per-pixel semantics are not preserved. The paper’s own measurements indicate that this approximation is visually mild, but it remains the principal source of the small PSNR/SSIM/LPIPS changes. By contrast, the paper repeatedly emphasizes that SLTree traversal does not alter LoD search semantics (Li et al., 29 Jul 2025).

In that sense, SLTarch is best understood as a scalable rendering architecture that regularizes irregular computation without discarding the hierarchical LoD model. Its defining insight is that real-time mobile PBNR requires not only fast splatting, but also a LoD-search substrate whose work units are bounded, schedulable, and streamable. The combination of SLTree, LTcore, divergence-free $\tau_s$0 splatting, and SPcore is the concrete system realization of that insight (Li et al., 29 Jul 2025).