SPcore: Scalable Splatting in Neural Rendering

• SPcore is a hardware accelerator in the SLTarch framework that processes pixels in 2×2 groups to eliminate per-pixel sparsity and control-flow irregularity.
• It transforms Gaussian transparency evaluations from per-pixel checks to group-level decisions, significantly reducing GPU warp divergence and boosting performance.
• Integrated with LTcore for level-of-detail search, SPcore enables large-scale point-based neural rendering with notable speedup and energy efficiency while maintaining high image quality.

SPcore is the splatting accelerator within SLTarch, an algorithm–architecture co-designed framework for scalable point-based neural rendering (PBNR). Its function is to remove the splatting-side inefficiency caused by sparse Gaussian–pixel interactions, which on GPUs induce severe warp divergence because adjacent pixels often integrate different subsets of Gaussians. In the SLTarch decomposition, LTcore handles level-of-detail (LoD) search, whereas SPcore restructures splatting into divergence-free, group-wise processing built largely on GSCore-style infrastructure but centered on a new SP unit. The defining algorithmic choice is to process pixels in $2 \times 2$ groups, evaluate Gaussian transparency once at the group center, and then either skip the whole group or send the Gaussian to four blending lanes (Li et al., 29 Jul 2025).

1. Position in the PBNR pipeline

SLTarch divides the PBNR pipeline into two major stages: LoD search and splatting. LoD search determines, for each Gaussian, which level of detail should be rendered. Splatting then projects and blends the selected Gaussians into the image. The paper treats both as scalability bottlenecks, but assigns SPcore specifically to the second one: splatting remains a large share of runtime and is impaired by control-flow irregularity during color integration (Li et al., 29 Jul 2025).

Within this organization, SPcore is not a standalone renderer. It is the splatting-side hardware block of a larger system that pairs it with LTcore for tree-based LoD search. The paper describes SPcore as a simple but principled augmentation to prior PBNR splatting hardware. The architectural baseline it extends is GSCore-style support for projection, duplication, and sorting; the substantive novelty is the splatting mechanism itself.

This system placement is important for interpreting the reported results. The paper’s headline improvements are measured for full-system configurations, not for an isolated splatting kernel. Accordingly, SPcore should be understood as the component that regularizes the back half of the rendering pipeline so that large-scene scalability is no longer limited by splatting-side divergence.

2. Computational bottleneck: sparse splatting and warp divergence

The paper characterizes standard splatting as a sparse integration problem. For each selected Gaussian, the renderer determines which pixels it intersects, sorts intersecting Gaussians by depth, and then integrates only those Gaussians that actually contribute to each pixel. The sparsity arises because any given Gaussian typically affects only a subset of pixels, and even adjacent pixels may have different intersection sets (Li et al., 29 Jul 2025).

On GPU-style SIMD/SIMT execution, this causes warp divergence. Threads execute in lockstep, but only a subset of them remain active for a given Gaussian–pixel test or blending step. The paper reports that this can reduce GPU utilization to as low as $31\%$ during splatting. The inefficiency is therefore not merely arithmetic; it is principally a control-flow and workload-regularity problem.

SPcore addresses this bottleneck by changing the granularity of the contribution decision. Rather than asking whether each Gaussian contributes to each pixel independently, it asks whether a Gaussian should be considered for a small neighboring pixel group. The paper motivates this by the observation that adjacent pixels typically integrate similar sets of Gaussians. That observation is the basis for the divergence-free execution model.

3. Group-wise splatting algorithm

The central algorithmic move in SPcore is to replace per-pixel transparency checks with group-level checks over $2 \times 2$ pixel groups. For each such group, the hardware computes the Gaussian transparency at the center of the group. If the Gaussian is sufficiently transparent there, the entire group is skipped; otherwise, the Gaussian is forwarded for blending across the four pixels in the group (Li et al., 29 Jul 2025).

The threshold used for this decision is

$\alpha < \frac{1}{255}.$

If the transparency falls below this cutoff, the Gaussian is not processed further for that group.

This changes the execution model in two ways. First, all four pixels in a group follow the same control path, so intra-group divergence is removed. Second, the splatting datapath becomes regular enough to admit a dedicated hardware realization with fixed-function control rather than branch-heavy per-pixel logic. The paper presents this as a deliberate approximation: traditional splatting performs fine-grained inclusion decisions, whereas SPcore coarsens the decision to the level of a small block.

The approximation is structured rather than ad hoc. It relies on local coherence in Gaussian visibility, not on a global simplification of the scene. That is why the paper attributes only a small rendering-quality loss to the change, while treating the gain in regularity as the dominant architectural benefit.

4. Microarchitecture and datapath organization

SPcore reuses several components from GSCore: a projection unit, a duplication unit, and a sorting unit. The paper states that these components account for only about $15\%$ of total execution time and are therefore left untouched. The principal addition is the new SP unit, which implements the divergence-free splatting rule (Li et al., 29 Jul 2025).

Each SP unit contains one $\alpha$-check unit and four blending units. The execution rule is direct. The $\alpha$-check unit evaluates the Gaussian’s transparency at the center of the $2 \times 2$ pixel group. If the Gaussian is effectively transparent enough, it is discarded for that group. Otherwise, it is propagated to the four blending units, which process the four constituent pixels.

The paper also highlights a microarchitectural simplification inside the $\alpha$-check path. Rather than directly computing the expensive exponential used in transparency evaluation, SPcore checks the power of the exponent rather than computing the full exponent. This reduces computational cost while maintaining the intended gating behavior of the approximation.

The upstream projection stage is likewise simplified. SPcore uses a basic $3$-$31\%$0 Gaussian-tile intersection test rather than more precise AABB/OBB-style tests. The paper justifies this simplification by the existence of later filtering in the pipeline, which makes more elaborate intersection handling unnecessary for the design goal at hand.

A compact rendering dataflow is therefore:

1. projection with a basic $31\%$1-$31\%$2 test,
2. duplication of work for splatting,
3. sorting by depth,
4. SP-unit processing over $31\%$3 groups with one transparency check and four blending lanes.

This datapath converts a sparse, branch-heavy kernel into a regular group-synchronous pipeline.

5. Hardware realization and measured system-level effects

The implementation described in the paper is concrete. The hardware is synthesized in TSMC $31\%$4 nm FinFET at a clock rate of $31\%$5 GHz. SPcore is composed of 4 projection units, 4 sorting units, $31\%$6 SP units, and a 256 KB double-buffered global buffer. The reported SPcore area is $31\%$7, while the total SLTarch area is $31\%$8 (Li et al., 29 Jul 2025).

The evaluation considers several configurations: GPU, GPU+LT, GPU+GS, LT+GS, and full SLTarch, where SLTarch combines LTcore and SPcore. Against a mobile GPU baseline, full SLTarch achieves $31\%$9 speedup on large-scale scenes and $2 \times 2$0 energy savings. Against existing accelerator designs, it achieves $2 \times 2$1 speedup and $2 \times 2$2 energy savings with comparable area. The paper further notes that GPU+GS achieves only about $2 \times 2$3 speedup over the GPU baseline.

These results are presented at system level, but they clarify SPcore’s role. On small-scale scenes, splatting dominates more heavily, so splatting hardware matters more directly. On large-scale scenes, LoD search becomes increasingly important, which is why LTcore is also necessary. SPcore’s contribution is to prevent splatting from remaining the residual bottleneck once LoD search is accelerated.

Rendering quality remains close to the unmodified pipeline. The paper reports that PSNR drops by about $2 \times 2$4 dB on average, while SSIM and LPIPS change only marginally. It attributes most of this small quality loss to the rasterization approximation introduced by SPcore rather than to LTcore or SLTree.

6. Relation to prior accelerator designs and design trade-offs

The paper’s explicit comparison point is GSCore. GSCore uses a finer-grained Gaussian-tile intersection strategy to reduce false-positive intersections. SPcore differs in objective and mechanism. Rather than pursuing finer splatting precision through more refined intersection handling, it changes the algorithm and hardware jointly so that divergence is removed at the source (Li et al., 29 Jul 2025).

This distinction is technically significant. GSCore’s finer-grained handling can reduce some inefficiency, but the paper argues that it adds non-trivial computational overhead, complicates the hardware design, and does not directly eliminate warp divergence arising from sparse per-pixel color integration. SPcore instead coarsens the transparency decision to a shared group-level decision and implements that decision in a dedicated SP unit.

The main trade-off is therefore between exact per-pixel control and regularized execution. SPcore accepts a slight approximation by evaluating transparency at the group level, but obtains a far more regular splatting pipeline. In the paper’s framing, this is the mechanism by which point-based neural rendering becomes scalable on the splatting side.

A concise characterization follows directly from the design: SPcore makes splatting scalable by replacing per-pixel sparse decision making with small-group, divergence-free processing, so that adjacent pixels share the same Gaussian integration path. Within SLTarch, that restructuring is the counterpart to LTcore’s treatment of LoD-search irregularity, and together the two blocks define the architecture’s scalability strategy for large-scale PBNR.