Refactor Gaussian splatting ops and extract utility functions

[fwilliams]

Summary

This PR is primarily code migration and renaming for consistency. It introduces no functional changes and removes some code duplication.

What is included:

• Renames 21 Gaussian splatting operator file pairs in ops/gsplat/ with descriptive names (e.g. GaussianProjectionForward -> ProjectGaussiansAnalyticForward, GaussianRasterizeForward -> RasterizeScreenSpaceGaussiansForward)
• Extracts shared CUDA utilities into utils/cuda/ (BinSearch, CubWrapper, Prefetch, WarpReduce, Alignment, CopyCoords, OpType) and utils/cuda/math/ (AffineTransform, Rotation)
• Extracts Gaussian-specific utilities into utils/gsplat/ (Gaussian2D, GaussianCameraAccessorCopy, GaussianCameras, GaussianMath, GaussianRasterize, GaussianRasterizeFromWorld, GaussianRasterizeOptionalInputs)
• Removes the template dispatch pattern (dispatchFoo<DeviceTag>) from op headers in favor of plain functions with internal device dispatch
• Deletes dead gsplat files: GaussianUtils.cpp/.h/.cuh, GaussianVectorTypes, GaussianMacros, GaussianRenderSettings, GaussianRigidTransform, GaussianCameraMatrixUtils, GaussianWarpUtils
• Renames GaussianSplatBinding.cpp -> GaussianSplatOps.cpp
• Updates all include paths in bindings, viewer, PLY I/O, and 16 C++ test files
• Removes OpType struct in favor of PyTorch's built-in at::opmath_type
• Removes GSPLAT_PRAGMA_UNROLL struct in favor of #pragma unroll

Part of #590 (PR 2: refactor gsplat directory).

Test plan

• C++ build succeeds
• C++ gtests: 39/41 pass (2 pre-existing flaky failures unrelated to this change: GaussianRasterizeForwardMaskedEdgeTile.NoDeadlock deadlock timeout, PredGatherIGemmTest CUDA launch failure)
• Python unit tests (cd tests && pytest unit -v)
• CI passes

[matthewdcong]

I think we also have some Python function naming leaking into the C++ side. For example, dispatch_rasterize_screen_space_gaussians_bwd in RasterizeScreenSpaceGaussiansBackward.cu. Unless that's intentional?

[fwilliams]

I think we also have some Python function naming leaking into the C++ side. For example, dispatch_rasterize_screen_space_gaussians_bwd in RasterizeScreenSpaceGaussiansBackward.cu. Unless that's intentional?

It's intentional. I'm trying to have the operator names and the binding names align. rasterize_screen_space_gaussians is more precise and constrasts against rasterize_world_space_gaussians.

[matthewdcong]

I think we also have some Python function naming leaking into the C++ side. For example, dispatch_rasterize_screen_space_gaussians_bwd in RasterizeScreenSpaceGaussiansBackward.cu. Unless that's intentional?

It's intentional. I'm trying to have the operator names and the binding names align. rasterize_screen_space_gaussians is more precise and constrasts against rasterize_world_space_gaussians.

Sorry I mean the conventions -- In the C++ code, it should be named rasterizeScreenSpaceGaussians in order to match with the rest of the code.

[harrism]

• Moves 21 Gaussian op file pairs from ops/gsplat/ into ops/ with descriptive names (e.g. GaussianProjectionForward -> ProjectGaussiansAnalyticForward, GaussianRasterizeForward -> RasterizeScreenSpaceGaussiansForward)

If we move all 3DGS ops into the top-level ops directory, it would be helpful to start all 3DGS files with a common prefix. Previously we had "Gaussian".

[fwilliams]

• Moves 21 Gaussian op file pairs from ops/gsplat/ into ops/ with descriptive names (e.g. GaussianProjectionForward -> ProjectGaussiansAnalyticForward, GaussianRasterizeForward -> RasterizeScreenSpaceGaussiansForward)

If we move all 3DGS ops into the top-level ops directory, it would be helpful to start all 3DGS files with a common prefix. Previously we had "Gaussian".

They are standalone ops now with a consistent naming that matches their python counterpart names. e.g. rasterize_screen_space_gaussians_fwd matches RasterizeScreenSpaceGaussiansForward.

I'd push back a bit on adding Gaussian as a prefix to each op file here since we don't do this for e.g. JaggedTensor or GridBatch (its SampleGridTrilinear not GridBatchSampleGridTrilinear). My medium term goal is to have the names of files and operators match from the _fvdb_cpp layer down to the ops directory. The gsplat directory was large with a lot common utilities that got moved out. Now its slimmed down to about 20 ops.

What are your thoughts?

[swahtz]

• Moves 21 Gaussian op file pairs from ops/gsplat/ into ops/ with descriptive names (e.g. GaussianProjectionForward -> ProjectGaussiansAnalyticForward, GaussianRasterizeForward -> RasterizeScreenSpaceGaussiansForward)

If we move all 3DGS ops into the top-level ops directory, it would be helpful to start all 3DGS files with a common prefix. Previously we had "Gaussian".

Why do we want to move the Gaussian-related ops out of ops/gsplat (or whatever ops subdirectory name we might want)? From a purely code organization standpoint I find it beneficial to have all the interdependent Gaussian-related ops together. What's the benefit of moving them?

[fwilliams]

• Moves 21 Gaussian op file pairs from ops/gsplat/ into ops/ with descriptive names (e.g. GaussianProjectionForward -> ProjectGaussiansAnalyticForward, GaussianRasterizeForward -> RasterizeScreenSpaceGaussiansForward)

If we move all 3DGS ops into the top-level ops directory, it would be helpful to start all 3DGS files with a common prefix. Previously we had "Gaussian".

Why do we want to move the Gaussian-related ops out of ops/gsplat (or whatever ops subdirectory name we might want)? From a purely code organization standpoint I find it beneficial to have all the interdependent Gaussian-related ops together. What's the benefit of moving them?

For the same reason we haven't split up GridBatch and all the JaggedTensor ops into their own folders. If we do this, we can segment out different ops into different directories based on their type but I think its not always a clean mapping. E.g. here spherical harmonics evaluation is a generic operator that we happen to use a lot in conjunction with Gaussian splatting.

We can certainly try and group .cu/.h pairs into folders for code organization purposes but I wonder if we shouldn't do this all in one go.

Personally, I prefer to have all the ops be in one big folder but I don't feel that strongly one way or another. If we're going to partition op files, I prefer to do it consistently.

[swahtz]

• Moves 21 Gaussian op file pairs from ops/gsplat/ into ops/ with descriptive names (e.g. GaussianProjectionForward -> ProjectGaussiansAnalyticForward, GaussianRasterizeForward -> RasterizeScreenSpaceGaussiansForward)

If we move all 3DGS ops into the top-level ops directory, it would be helpful to start all 3DGS files with a common prefix. Previously we had "Gaussian".

Why do we want to move the Gaussian-related ops out of ops/gsplat (or whatever ops subdirectory name we might want)? From a purely code organization standpoint I find it beneficial to have all the interdependent Gaussian-related ops together. What's the benefit of moving them?

For the same reason we haven't split up GridBatch and all the JaggedTensor ops into their own folders. If we do this, we can segment out different ops into different directories based on their type but I think its not always a clean mapping. E.g. here spherical harmonics evaluation is a generic operator that we happen to use a lot in conjunction with Gaussian splatting.

We can certainly try and group .cu/.h pairs into folders for code organization purposes but I wonder if we shouldn't do this all in one go.

Personally, I prefer to have all the ops be in one big folder but I don't feel that strongly one way or another. If we're going to partition op files, I prefer to do it consistently.

But the reality is that there is no functionality that uses the spherical harmonics evaluation operators outside of Gaussian splatting and the arguments to the SH evaluation ops are specific to the Gaussian splatting toolchain (e.g. the means and projected radii arguments). Until there's a reason to move them into a more generic folder, I don't see why we would change that from where they stand today.

[harrism]

Unless it's a public interface that we want to simplify #include lines for, I prefer to have things more organized rather than one big dump folder.

[fwilliams]

Unless it's a public interface that we want to simplify #include lines for, I prefer to have things more organized rather than one big dump folder.

Unless it's a public interface that we want to simplify #include lines for, I prefer to have things more organized rather than one big dump folder.

Sounds good - I moved it into a folder for better organization. Let me know if you guys are happy with the PR otherwise!

[swahtz]

Loving the removal of the templated dispatch functions everywhere. Just a few docs/naming and other improvement comments. Thanks

[matthewdcong]

If we're going to keep the splatting operators in a subdirectory, can we just keep the gsplat folder name instead of introducing a new gaussian_splatting folder? It would make the changes easier to follow through the history in the short term, and we can rename it in a straightforward follow up PR.

[fwilliams]

Done -- renamed back to gsplat/ in the latest push.

[matthewdcong]

Sorry for the continued comments. I have some more feedback after checking out your branch and playing around with it.

[swahtz]

Looking good, thanks for taking on board my notes and explaining the changes.

[matthewdcong]

Can we update the PR and title description to reflect the latest since it ends up going into the final squashed MR? Also, please add that GSPLAT_PRAGMA_UNROLL has been replaced by #pragma unroll.

[matthewdcong]

Modified the description and title. Lmk if anything is off