LTcore: Accelerating LoD Search

• LTcore is the dedicated hardware block for LoD search in SLTarch, optimizing irregular tree traversal by dynamically streaming subtrees.
• It uses the SLTree data structure to partition the LoD tree into bounded subtrees, reducing DRAM traffic by up to 76.5% compared to exhaustive GPU search.
• Its microarchitectural design—including a Subtree Queue, Cache, and parallel LT units—ensures balanced workload and significant performance gains in large-scale scenes.

LTcore is the dedicated hardware block for the LoD-search stage in SLTarch, an algorithm-architecture co-designed framework for scalable point-based neural rendering. In SLTarch, point-based neural rendering is split into two stages—LoD search, which finds a “cut” in the hierarchy of Gaussians above a target LoD, and splatting, which rasterizes the selected Gaussians. LTcore sits in front of SPcore, streams in small “subtrees” of the global LoD tree via the SLTree data structure, traverses each subtree in parallel on multiple LT units, and emits the IDs of Gaussians that satisfy the LoD criterion, thereby assembling the final rendering queue (Li et al., 29 Jul 2025).

1. Pipeline role and computational motivation

LTcore is defined by its role in mitigating the principal bottlenecks of LoD search in point-based neural rendering. A canonical LoD tree is highly irregular: each node can have an unfixed number of children, and the camera-dependent cut changes every frame. Under these conditions, GPU implementations either perform an exhaustive traversal of all $N$ nodes, which wastes work and memory bandwidth, or assign each warp a subtree, which leads to severe workload imbalance and random DRAM accesses. LTcore and SLTree address this by imposing structure: subtrees are of bounded size $\tau_s$, laid out contiguously in DRAM, and scheduled dynamically onto homogeneous LT units (Li et al., 29 Jul 2025).

This architectural placement is central to the SLTarch decomposition. LTcore handles LoD search, while SPcore handles splatting. The separation is not merely modular; it isolates the irregular tree-traversal phase from the rasterization phase, allowing the search stage to be redesigned around subtree streaming, queue-driven scheduling, and on-chip caching rather than warp-centric SIMT execution. In the system-level framing of SLTarch, LTcore is therefore a specialized tree traverser rather than a general-purpose accelerator (Li et al., 29 Jul 2025).

2. Microarchitectural organization

LTcore consists of a Subtree Queue, a Subtree Cache, a 2×2 array of LT units, and an Output Buffer. The Subtree Cache is a 4-way set-associative SRAM of 128 KB total; the Output Buffer is double-buffered with 2 banks × 8 KB; and each LT unit is a simple FSM plus a tiny ring-buffer SRAM that holds its current subtree index range and “program counter” (current NID) (Li et al., 29 Jul 2025).

Component	Configuration	Function
Subtree Queue	Small on-chip FIFO	Tracks pending subtree IDs
Subtree Cache	4-way, 128 KB	Holds subtree nodes indexed by SID
LT units	2×2 array	Traverses subtrees in parallel
Output Buffer	2 banks × 8 KB	Buffers selected NIDs

The Subtree Queue has two logical halves that track which SIDs are already resident in Subtree Cache versus which still need to be loaded. This guarantees that an LT unit never grabs a SID before its subtree data are in cache, avoiding LT-unit stalls. The Subtree Cache is tagged by SID, and each way holds up to $\tau_s$ entries of subtree nodes in DFS order. Each entry stores $$\{\text{NID}, \text{AABB}, \text{remaining\_subtree\_size}, \text{child\_SIDs}, \text{LoD parameters}\}$$, and short subtrees are zero-padded to $\tau_s$. Replacement is round-robin, with eviction constrained so that no LT unit is still working on the evicted way’s SID. The Output Buffer decouples traversal from downstream consumption: as one bank fills with selected NIDs, the other drains into the global buffer or GPU for the splatting stage (Li et al., 29 Jul 2025).

3. Subtree traversal and execution semantics

Each LT unit executes a fixed traversal loop over subtree-local node indices. When an LT unit has no current SID, it dequeues a loaded subtree ID from the Subtree Queue, initializes its program counter to the first node in the subtree, and sets subtree_end from the subtree size. On each cycle, it reads the current node metadata from the Subtree Cache using $(\text{SID}, \text{NID})$, performs a frustum intersection test and an “is this node the cut?” LoD check, and then updates its program counter according to the test outcome (Li et al., 29 Jul 2025).

The control actions are specific. If the current NID exceeds subtree_end, the LT unit is done and requests another SID. If the node is a cut node, the LT unit writes the NID to the Output Buffer and skips the entire subtree by advancing NID += remaining_size. If the node misses the frustum, it also skips the subtree. Otherwise, it advances to the next node with NID ← NID + 1. If it reaches a leaf, it enqueues that node’s child-SIDs to the Subtree Queue. This realizes a subtree-based cut search in which skipped regions are pruned by metadata rather than traversed explicitly (Li et al., 29 Jul 2025).

The memory behavior is equally deliberate. load_subtree_if_needed() pulls $\tau_s$ consecutive nodes from DRAM into one cache way. The summary specifies that subtrees are stored contiguously in DRAM in BFS order, making the stream DRAM-row friendly. A plausible implication is that LTcore’s traversal semantics are coupled to a storage layout chosen to regularize memory access at subtree granularity rather than node granularity (Li et al., 29 Jul 2025).

4. Performance model and scaling behavior

The formal model characterizes LTcore using four parameters: $N$, the total number of Gaussians or tree nodes; $H$, the tree height; $\tau_s$, the subtree size limit; and $\tau_s$0, the number of parallel LT units, with $\tau_s$1 in the prototype. For a GPU baseline, a naive exhaustive LoD search is modeled as

$\tau_s$2

where $\tau_s$3 is the per-node traversal latency and $\tau_s$4 is the per-cut test cost scaling with $\tau_s$5 (Li et al., 29 Jul 2025).

SLTree partitions the hierarchy into roughly $\tau_s$6 subtrees of size at most $\tau_s$7, and LT units compete for subtrees from the queue. The resulting LTcore latency is approximated by

$\tau_s$8

where $\tau_s$9 because on-chip cache hits dominate, $\tau_s$0 amortizes enqueue, dequeue, and subtree-switch cost per subtree, and $\tau_s$1 captures residual dependence on tree height. The dominant term is $\tau_s$2 once $\tau_s$3 and subtrees fully load; $\tau_s$4 is small; and $\tau_s$5 is negligible for balanced subtrees unless the cut falls very deep (Li et al., 29 Jul 2025).

The reported empirical behavior is consistent with this model. With $\tau_s$6 and $\tau_s$7, overall LoD-search speedup over GPU is 2.3× → 3.6× after subtree merging for small-scale scenes and 5.2× → 7.8× after merging for large-scale scenes. The placement of subtree merging in these ranges indicates that shaping the subtree size distribution is part of the effective scaling strategy rather than a secondary optimization (Li et al., 29 Jul 2025).

5. Removal of workload imbalance and memory irregularity

LTcore addresses imbalance first through static regularization by SLTree. Because subtrees are all of size at most $\tau_s$8, the worst-case work per LT unit is bounded by approximately $\tau_s$9 nodes. Subtree merging—defined here as merging any sibling subtrees smaller than $$\{\text{NID}, \text{AABB}, \text{remaining\_subtree\_size}, \text{child\_SIDs}, \text{LoD parameters}\}$$0—further tightens the size distribution. This converts a hierarchy with unfixed branching into a workload expressed as bounded subtree tasks (Li et al., 29 Jul 2025).

Dynamic balancing is then supplied by the Subtree Queue. At runtime, camera pose changes alter which portions of the tree are active, but LT units always pull the next needed subtree, so no unit sits idle. The queue therefore replaces static warp-to-subtree assignment with dynamic subtree dispatch. In tandem with contiguous subtree layout, this also regularizes memory behavior: each subtree is contiguous in memory, every DRAM access is a burst of $$\{\text{NID}, \text{AABB}, \text{remaining\_subtree\_size}, \text{child\_SIDs}, \text{LoD parameters}\}$$1 nodes in BFS order, and irregular per-node child pointers are replaced by simple enqueue operations at leaves (Li et al., 29 Jul 2025).

The quantitative effects are reported directly. DRAM traffic is reduced by 76.5% for small-scale scenes and 69.6% for large-scale scenes relative to exhaustive GPU search. The dynamic load imbalance, measured as $$\{\text{NID}, \text{AABB}, \text{remaining\_subtree\_size}, \text{child\_SIDs}, \text{LoD parameters}\}$$2 of node visits across 64 GPU threads, was $$\{\text{NID}, \text{AABB}, \text{remaining\_subtree\_size}, \text{child\_SIDs}, \text{LoD parameters}\}$$3; LTcore erases this imbalance. The architectural significance is that LTcore does not merely accelerate traversal; it changes the unit of work from irregular node expansion to streaming subtree evaluation (Li et al., 29 Jul 2025).

6. Integration within SLTarch and system-level effects

LTcore is inseparable from SLTree at the data-structure level and from SPcore at the pipeline level. SLTree is the offline partitioning layer that transforms the canonical LoD tree into subtrees. At runtime, a small host CPU enqueues the top-level subtrees of SLTree to LTcore’s Subtree Queue, LTcore outputs a packed list of NIDs that form the LoD cut, and this list is DMA’d into the global buffer for SPcore. The summary also notes that a small CPU or DMA engine is used to prefetch subtrees into the on-chip Subtree Cache (Li et al., 29 Jul 2025).

The comparison to GPU execution clarifies LTcore’s system role. In a pure GPU implementation, up to 70% of point-based neural rendering time in large scenes is spent in LoD search, and exhaustive search drags frame time to $$\{\text{NID}, \text{AABB}, \text{remaining\_subtree\_size}, \text{child\_SIDs}, \text{LoD parameters}\}$$4 ms. In a GPU+LT configuration, with the GPU doing splatting and LTcore doing LoD search, LoD time decreases by 5× and total frame time decreases by 3.2× for large scenes. In the full SLTarch configuration, comprising LTcore and SPcore, end-to-end point-based neural rendering achieves 3.9× speedup and 98% energy savings versus a mobile Ampere GPU; compared to existing accelerator designs, SLTarch achieves 1.8× speedup with 54% energy savings (Li et al., 29 Jul 2025).

These figures situate LTcore as a bottleneck-oriented accelerator. Its immediate output is only a list of selected node IDs, but because LoD search can dominate total frame time, accelerating this phase materially changes overall system behavior. A plausible implication is that LTcore’s value is highest in scenes where tree traversal irregularity, not splatting throughput, is the primary limiting factor (Li et al., 29 Jul 2025).

7. Area, power, tuning parameters, and limitations

LTcore is described as a small block relative to the full SLTarch design. Its total area is 0.14 mm² in TSMC 16 nm, out of 1.90 mm² for full SLTarch. Of this, the 128 KB Subtree Cache accounts for approximately 0.10 mm², while the Subtree Queue, LT units, and Output Buffer together account for approximately 0.04 mm². Power consumption is approximately 2–3 W in worst-case DRAM streaming, compared with a 50 W GPU baseline (Li et al., 29 Jul 2025).

The design is not parameter-free. The subtree size limit $$\{\text{NID}, \text{AABB}, \text{remaining\_subtree\_size}, \text{child\_SIDs}, \text{LoD parameters}\}$$5 must be tuned: if it is too large, per-subtree imbalance creeps back; if it is too small, queue overhead rises through larger $$\{\text{NID}, \text{AABB}, \text{remaining\_subtree\_size}, \text{child\_SIDs}, \text{LoD parameters}\}$$6. The architecture also requires an offline SLTree construction pass and minor DRAM layout changes to store subtrees contiguously. These are not incidental implementation details; they are part of the mechanism by which LTcore converts irregular traversal into a streaming pipeline (Li et al., 29 Jul 2025).

The reported limitations are correspondingly specific. Worst-case scenes with extremely high-fanout roots can create momentary bursts of subtree enqueue activity. This does not negate the queue-driven approach, but it defines a boundary condition in which the enqueue path becomes briefly stressed. Within the framing of SLTarch, LTcore is therefore best understood as a low-power, specialized traverser whose efficiency depends on bounded subtree granularity, queue-mediated dynamic scheduling, and a memory layout tailored to contiguous subtree access (Li et al., 29 Jul 2025).