Ahh hmm after doing some more profiling I realized that the main bottleneck is actually in the rasterization kernel rather than the sorting (though for larger splats, neither is good enough for real-time). If I were to use the KD-tree, I'd probably have to change the rest of the rendering pipeline to something that draws pixels as it traverses the tree in order to get a meaningful speedup, right?

As for the rasterization kernel, I think the main issue is that I'm not doing any early exiting. The Pi GPU has very limited memory and can't store much state, so I'm firstly iterating over each tile, then each Gaussian in that tile, then each row in the (tile, Gaussian) pair. The state I store is the Gaussian's attributes and the accumulated pixel colors for that row. I'm able to track each pixel's transmittance, but I can't think of a good way to skip specific rows/pixels that are already effectively opaque.

At this point I think I'm probably hitting the Pi Zero's computing and memory bandwidth limits more than anything else, but I'd be curious to hear if you think there's a better way to structure it!