Bound world-space rasterization channel loop unrolling to improve compile times - #743
Bound world-space rasterization channel loop unrolling to improve compile times#743matthewdcong wants to merge 1 commit into
Conversation
Limit full channel-loop unrolling to kernels with at most 32 channels and use four-way unrolling for larger specializations. Keep the templated warp reduction for small kernels while using the runtime-sized reduction for larger backward kernels. For CUDA 13.2 targeting sm_120, this reduces forward compile wall time from 165.50s to 71.02s (57.1%, 2.33x) and backward compile wall time from 301.05s to 82.72s (72.5%, 3.64x). Add 33- and 513-channel coverage for perspective and orthographic cameras, and record the compilation and kernel-resource measurements. Signed-off-by: Matthew Cong <mcong@nvidia.com>
swahtz
left a comment
swahtz
left a comment
There was a problem hiding this comment.
That's great, I assume there's no real runtime performance impact?
|
I measured this on an RTX PRO 6000 Blackwell (sm_120), CUDA 13.0, using a synthetic but reasonably sized world-space scene: 512x512 image, 16,384 Gaussians, 16 candidates/tile, and 512 feature channels. These are median CUDA-event kernel times over 30 runs after 8 warmups.
I repeated the run and obtained essentially identical values. So there is a substantial forward-performance tradeoff at 512 channels, despite the backward improvement; this is not runtime-neutral for this workload. |
|
Follow-up with the larger requested fixture: 2048x1024, 9,994,240 Gaussians (1,220 candidates in each 16x16 tile), and 512 feature channels. This is a single pinhole camera with the Gaussians distributed within their assigned tiles. The feature tensor alone is about 20.5 GB; peak process GPU memory was about 50 GB. Same RTX PRO 6000 Blackwell / CUDA 13.0 system, using median CUDA-event time from 5 samples after 2 warmups:
So this scales the same direction as the earlier forward result, and the larger workload also turns the backward path into a regression. This is synthetic rather than a trained capture, but it exercises the target channel specialization and a genuinely large tiled scene. |
|
I ran a smaller sweep to look for a compile/runtime compromise. Fixture: 2048x1024, 1,998,848 Gaussians (244 per 16x16 tile), 512 channels; median CUDA-event time from 5 samples after 2 warmups.
For backward, 16 looks like the practical sweet spot: 15.6% faster than the full-unroll base; 32 adds only 0.4% while increasing uncached incremental compile time slightly (81.6 s vs. 83.4 s). For forward, none of 4/8/16/32/64 is close to full unrolling: all remain about 4.4–4.6x slower. So I do not think a different partial-unroll factor alone solves forward. My recommendation would be to use 16-way unrolling for backward, but either retain full unrolling for forward 512/513 or pursue a structural channel-tiling redesign there. |
|
Compile-time context I should have included:
Those incremental numbers are intentionally not directly compared to the PR’s clean full-build baseline; I did not measure unroll 4 and full unroll with that exact same protocol, so presenting them as a complete compile-time comparison would have been misleading. They do show that backward 16 retains roughly the PR-level compilation cost, while larger caps trend upward. I should have stated this distinction in the sweep comment. |
2 participants
Limit full channel-loop unrolling to kernels with at most 32 channels and use four-way unrolling for larger specializations. Keep the templated warp reduction for small kernels while using the runtime-sized reduction for larger backward kernels.
For CUDA 13.2 targeting sm_120, this reduces forward compile wall time from 165.50s to 71.02s (57.1%, 2.33x) and backward compile wall time from 301.05s to 82.72s (72.5%, 3.64x).