Handle duplicate pixels in sparse pixel gaussian rendering

[harrism]

Summary

• Deduplicate pixel coordinates at the binding layer (deduplicatePixels) before passing to computeSparseInfo and rasterization kernels, then scatter results back via index_select. This avoids any CUDA kernel modifications while correctly handling duplicate (batchIdx, row, col) entries that would otherwise cause incorrect tile bitmasks.
• Handle edge cases: single-list JaggedTensors with empty jidx, correct jlidx passthrough for ldim() consistency, and reducing numContributingGaussians to unique-pixel space for the contributing IDs kernel.
• Add comprehensive C++ unit tests for deduplicatePixels (20 tests covering empty, single, all-unique, duplicates, multi-batch, round-trip reconstruction, and per-batch offset validation) and Python end-to-end tests for all sparse render APIs with duplicate pixels (6 tests covering depths, images, backward gradients, num_contributing, contributing_ids, and multi-camera).

Fixes #106

Test plan

• C++ DeduplicatePixelsTest: 20/20 pass
• C++ GaussianComputeSparseInfoTest: 14/14 pass
• Python TestGaussianRenderSparseDuplicatePixels: 6/6 pass

[blackencino]

LGTM, Ship it!

Looking specifically at the actual de-duplication, every part of what exists in the C++ there could have been done as a torch python operation. Is there a specific reason this needed to be compiled?

[harrism]

Looking specifically at the actual de-duplication, every part of what exists in the C++ there could have been done as a torch python operation. Is there a specific reason this needed to be compiled?

No reason other than that the current implementation is all C++. The original proposal was a much more complicated approach that used custom kernels. Performance may be lower in Python, naturally, but I don't think this operation will be a bottleneck.

[swahtz]

Looks great I just had a few potential optimization suggestions since these will get called on every rendering iteration.

I was also wondering for the unit tests if it would be worth having a test where all pixels in each batch are duplicates or perhaps that's redundant with the tests were just some pixels are duplicates.

[harrism]

Great suggestions @swahtz . Implemented your two optimizations and found one other and a stale comment. Also added your suggested maximum compression test case.

[fwilliams]

A few small notes on the algorithm. I think this could be tightened up to use fewer allocations. This could also be implemented with fixed up front memory using a couple of cuda kernels if you wanted to do it that way. I'll defer to you as to which you think is better.

[harrism]

I decided against the custom kernel approach because by definition these are low-cost operations in terms of memory and computation. For sparse rendering, N (number of pixels) should be small -- say 5-50K. I estimate memory savings of a custom kernel to be at most ~1MB at that scale. Even if we render at the scale of 500K pixels (25% of a 1080p image) we're talking only 10MB savings. On the scale of 3DGS memory usage, this is peanuts.

The main reason for custom kernels here would be launch overhead and possibly synchronization reduction. But I don't think that should be addressed until it is determined to be a bottleneck.

[harrism]

@fwilliams implemented the small optimizations you suggested. Torch cumsum_ doesn't work on bool tensors in CUDA, so had to cast it, so the memory savings is reduced a bit but there's still about 8N bytes savings (1 fewer allocation) for that one (rather than 16N).