How does 3D Gaussian Splatting render an image, and why is sorting the slow part?

The short answer: project, sort by depth, blend front to back

3D Gaussian Splatting renders an image by drawing a scene made of many small, soft, ellipse-shaped blobs called Gaussians. For each frame the renderer projects every Gaussian onto the screen, sorts the ones that land in each patch of the image from nearest to farthest, and then blends their colors front to back for every pixel until the pixel is effectively opaque.

There is no neural network running at view time and no triangle mesh. That is why splats can be viewed in real time, but it also means the ordering step has to be redone every frame, and that is where much of the cost hides.

How the standard tile-based rasterizer works

The usual renderer splits the screen into 16 by 16 pixel tiles, and on a GPU each tile is handled by one block of 256 threads. Gaussians whose projected footprint, taken out to three standard deviations, falls outside the view are culled, and ones too close to the camera are rejected to avoid numerical trouble.

Every surviving Gaussian is copied once for each tile its footprint overlaps. A Gaussian that touches four tiles becomes four entries. Each entry gets a key with the tile number in the upper bits and the depth in the lower bits, and one big parallel radix sort orders all the entries at once. After the sort, each tile's entries sit together, already in depth order.

Each tile then walks its list front to back. A pixel accumulates color as the sum of each Gaussian's color times its opacity times the light still passing through, and that remaining transmittance shrinks with every Gaussian blended. When every pixel in a tile is nearly opaque, the tile stops early, which saves a lot of work in dense scenes.

Why sorting and tiles waste work

The tile scheme trades accuracy of placement for simplicity. Footprints are approximated with conservative boxes, so many Gaussian-tile pairs are false positives that touch the box but not any real pixel. Large Gaussians get duplicated into many tiles, and because each tile is sorted separately, the same Gaussian is ordered again and again with no reuse across tile borders.

Tile size pulls in two directions. Work on the GS-TG accelerator reports that in one test scene, 8 by 8 tiles produced 18.3 times more intersecting tiles per Gaussian than 64 by 64 tiles, and that most Gaussians in a tile also appear in its neighbors: 84 percent at 16 by 16. Bigger tiles make sorting cheaper but force pixels to process Gaussians that barely affect them, which is why 16 by 16 usually wins overall. GS-TG's fix is to sort once for a 64 by 64 group and give each Gaussian a small bitmask saying which 16 by 16 tiles inside the group it really touches.

A different approach: scanlines that reuse the depth order

SLGS, presented at PACT 2026 by researchers at Yonsei University, GIST and Georgia Tech, splits the image into 32 by 32 macro-tiles and renders each one along scanlines instead of square tiles. Each macro-tile chooses horizontal or vertical scanlines by a majority vote of the Gaussians' main stretch direction, since projected splats are usually long in one direction.

Only the first scanline is fully sorted. Later scanlines update that order with entry and exit events as Gaussians start and stop covering the line, rather than sorting from scratch. Each Gaussian's exact coverage on the line becomes a 32-bit pixel mask, which removes the false positives, and Gaussians that do not overlap are packed together so a 32-lane compositor stays busy, skipping lanes whose pixels are already opaque.

As a small hardware block attached to a GPU, the authors report 2.36 times the speed of the strongest earlier splat accelerator and 12.43 times the original 3DGS software on a Jetson Orin NX, with image quality within 0.02 dB PSNR of the original across 11 scenes. These are simulated hardware results from the paper, not a chip you can buy.

What this means for viewing splats on small devices

The lesson across these designs is that splat rendering speed depends less on raw arithmetic than on how often the same Gaussians are found, copied and re-sorted. Software viewers can benefit from the same ideas: tighter footprints than boxes, sharing sort results across neighboring tiles, and stopping early on opaque pixels. Dedicated hardware takes those ideas further, which is where phones, headsets and other battery-powered devices are likely to see the biggest gains.