PIM-Accelerated Gradient Accumulation for 3DGS-SLAM

Removing atomic contention from the rendering backward pass with bank-local reduction

01Motivation

In a 3D Gaussian Splatting SLAM pipeline the time goes into tracking and mapping, and inside those the rendering backward pass dominates. That pass is not short of arithmetic — it is short of independent writes. Many fragments contribute gradients to the same gaussian, so the accumulation becomes a pile of atomic adds onto the same address, and the hardware serialises them. The reformulation here is to stop treating it as a compute problem: bin fragments by memory bank on the host and reduce them inside the bank, so there are no global atomics left to contend for.

Key question Can bank-local reduction inside PIM remove the atomic contention that dominates 3DGS-SLAM's rendering backward pass?

02System problem

The workload takes P fragments, each carrying a gaussian_id and a gradient vector of length D, and produces an accumulator array acc[G][D]. On the GPU each fragment does an atomicAdd into acc[gaussian_id]; when many fragments share a gaussian those adds serialise, and the cost grows with the skew of the distribution rather than with the number of fragments. The PIM path bins fragments by bank on the host (gaussian_id modulo the bank count), accumulates locally inside each bank, and writes back only what is needed.

The same fragments on two paths. On the GPU many updates converge on one accumulator element through atomicAdd and serialise there; binned by bank, the same updates are spread across banks and each bank sums its own share in parallel.

03Approach

The four stages that all have to be counted: bin on the host, transfer, accumulate in PIM, write back. A comparison that times only the accumulate stage is not a fair comparison.

1Isolate the workloadExtract the rendering backward pass into a standalone gradient-accumulation benchmark driven by synthetic or trace-derived fragments, so contention can be varied on purpose.

2Build the GPU baselinesTwo baselines, not one: a global atomicAdd version and a block-level reduction version that already removes most of the atomics. The second is what the PIM path actually has to beat.

3Implement the PIM pathBank-local reduction in the SAIT PIMSimulator with host-side binning, keeping the split of responsibilities explicit: the host bins, PIM generates addresses and accumulates.

4Sweep contentionVary P, G, D, and the skew of the fragment-to-gaussian distribution, and report speedup, scaling, and a per-stage breakdown rather than a single number.

04Current findings

Correctness first

GPU and PIM accumulators are compared element-wise under a fixed seed, with maximum absolute error and relative error reported, before any timing number is taken seriously.

What gets measured

GPU kernel latency and atomic pressure on one side; PIM cycles plus host-side data movement on the other, with binning, transfer, accumulation, and write-back timed separately.

Evidence target

The claim to prove is a crossover: as the distribution becomes more skewed, GPU atomics should degrade sharply while bank-local reduction stays flat or degrades slowly. The sweep that would show it has not been run yet.

Portfolio note Portfolio note: this page is not a paper. It shows the question, the method, and the judgement calls as they stand today, and it is rewritten as results arrive.

05What went wrong

Symptom

Early PIM runs produced either incorrect accumulators or speedups too large to be explained by the compute and memory behaviour of the workload.

Hypotheses

The host was doing work that belonged to PIM; or the payload encoding between host and simulator did not match; or the binning layout broke the bank-locality assumption the whole design rests on.

Tests

Locked the inputs and compared GPU-Atomic, GPU-BlockReduce, and PIM-Reduce on the identical fragment set, timing the binning, accumulation, and write-back stages separately instead of end to end.

Fix

Defined the responsibilities strictly — host bins, PIM generates addresses and accumulates — made the binning layout explicit, and reported per-stage latency in every result.

Takeaway

A PIM speedup is only meaningful with the staging cost attached. A number that hides the host's share of the work is not a comparison, it is an accounting choice.

06Next steps

Run the contention sweep over P, G, D, and distribution skew, and produce the speedup-versus-skew curve the whole argument rests on.
Drive the benchmark from real 3DGS-SLAM traces instead of synthetic fragments, so the skew matches what rendering actually produces.
Report host binning as part of the PIM total, and find the skew below which paying for binning is not worth it.