Pith. sign in

REVIEW 2 major objections 4 minor 4 references

Rendering Point Clouds with Compute Shaders

T0 review · 2 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper argues that replacing the OpenGL point pipeline with a compute-shader rasterizer built on atomicMin into a 64-bit framebuffer renders point clouds up to ten times faster while adding 40-bit depth precision.

desk verdict A short, honest compute-shader rasterizer paper whose genuinely new bit is a 40-bit integer depth encoding; the 'up to 10x' speedup is a plausible best-case, not yet a general result. read the letter →

arxiv 1908.02681 v1 pith:6TDUZMZA submitted 2019-08-07 cs.GR

Markus Schütz , Michael Wimmer This is my paper · ORCID
classification cs.GR
keywords point-basedrenderingpointcloudLIDARGPGPUcomputeshaderatomicMindepthbufferprecisionsurfacesplatting
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Point clouds are usually drawn by handing point primitives to the OpenGL pipeline, but this paper argues that a custom rasterizer written entirely in compute shaders can do the same job much faster. The central proposal is to encode color and depth into one 64-bit integer, with depth in the high 40 bits, and write fragments into a shader storage buffer using an atomic minimum operation, so only the closest point survives per pixel. On large LIDAR scans, the authors measure up to ten times higher frame rates than GL_POINT rendering, and a high-quality splatting variant that averages overlapping front-surface points is still two to three times faster. The same buffer gives a 40-bit integer depth value with uniform or customizable precision, which avoids the depth-fighting and precision loss of standard floating-point depth buffers. A sympathetic reader would take away that compute-shader rasterization is a practical alternative for one-pixel point rendering, not just a research curiosity.

What carries the argument

The load-bearing mechanism is the atomicMin operation applied to a 64-bit shader storage buffer used as a custom framebuffer. Color and depth are packed into one uint64: depth occupies the upper 40 bits and RGB the lower 24 bits, so a single atomicMin keeps the fragment with the smallest depth while using color only to break exact ties. This one operation replaces the depth test, rasterization, and fragment write of the fixed pipeline, and it is what makes both the speed gain and the custom 40-bit depth precision possible. For the splatting variant, the same depth buffer is reused in a second pass that sums and averages fragment colors within a 1% depth window.

What would settle it

Run the Retz and Morro Bay datasets through both renderers with two-pixel point sizes and shuffled point order; if the atomicMin compute path is no longer faster than GL_POINT in that regime, the central performance claim fails outside the one-pixel case.

Watch

Extended reading notes

Core claim

The paper's claim is that the fixed-function OpenGL point pipeline is not the fastest way to draw point clouds on modern GPUs. The authors implement a two-pass compute-shader rasterizer: the first pass performs atomicMin operations on a 64-bit framebuffer in which the most significant 40 bits hold an integer depth and the least significant 24 bits hold RGB; the second pass reads that buffer into a texture and clears it. Because atomicMin compares the full 64-bit value, the point with the smallest depth wins, with color as a tie breaker. Depth is computed in double precision and scaled by 1000 before being stored, giving millimeter resolution across a range of one million kilometers, and the 40-bit range can be partitioned into custom precision zones. A second method implements high-quality surface splatting: after building the depth buffer, it averages the colors of all fragments whose linear depth is within 1% of the closest fragment in that pixel. The reported result is that this compute-based rasterizer renders the tested LIDAR scenes between 1.64 ms and 6.41 ms on a 2080 TI, compared with 5.71 ms to 60.26 ms for GL_POINT, while the splatting variant remains faster than the traditional pipeline.

Load-bearing premise

The speed advantage is measured at a point size of exactly one pixel; at larger point sizes the compute method scales roughly linearly while OpenGL scales better, and the results also depend on point order and viewpoint.

Editorial extensions

If this is right

  • Large LIDAR and photogrammetric point clouds can be viewed at interactive rates without decimation when points map to single pixels.
  • Applications that need precise depth, such as measurement or occlusion queries, can use the 40-bit integer depth instead of fighting floating-point depth-buffer artifacts.
  • The high-quality splatting pass shows that blended, anti-aliased point rendering can be achieved at higher speed than the traditional primitive.
  • WebGPU renderers, where GL_POINT is emulated inefficiently on some platforms, can adopt this pattern directly.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The same 64-bit atomic trick could be extended to order-independent transparency by using atomicMax or by packing an opacity or priority field into the high bits, something the paper does not explore.
  • The performance comparison is likely regime-dependent; a practical rule of thumb may be to switch to the compute rasterizer only when projected point size is near one pixel, and to reserve OpenGL for large splats.
  • The 1% depth window for splatting could be made adaptive to local point density or viewing distance, which the authors leave as future tuning.
  • The technique's value may be largest for progressive streaming renderers, where incoming points arrive in arbitrary order and the atomicMin buffer makes the result order-independent in depth.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 4 minor

Summary. The paper proposes a compute-shader-based point cloud rasterizer that uses atomicMin on a 64-bit integer encoding color and depth into a custom framebuffer, along with a splatting variant that blends overlapping fragments. The authors claim up to a 10x speedup over rendering with GL_POINT primitives, a 40-bit integer depth buffer with uniform or customizable precision, and higher frame rates with high-quality splatting. Performance is evaluated on three large point cloud datasets (Heidentor, Retz, Morro Bay) on two GPUs, with timings reported in Table 1. The paper also discusses limitations, noting that the compute method is best suited for one-pixel point sizes and that results vary with point order and viewpoint.

Significance. If the performance claim is robust, the approach offers a simple and portable alternative to traditional point rendering that is particularly relevant for WebGPU environments, where GL_POINT emulation is slow. The open-source implementation is a strength, and the 40-bit depth encoding is a concrete, useful improvement over standard depth buffers. However, the significance is moderated by the fact that the headline speedup rests on single unrepeated measurements and is explicitly conditional on one-pixel point sizes and favorable input order. The paper is internally consistent and honestly lists its limitations, but the evidence as presented does not yet establish a general algorithmic speed advantage.

major comments (2)
  1. [Section 3, Table 1] The reported rendering times are single measurements with no variance, and the manuscript does not specify the camera path, point order, or timing methodology. Because Section 3 states that results vary greatly with point order and viewpoint and that shuffling points reduces efficiency, the single measurements may not be representative, and the abstract's 'up to 10 times higher performance' claim is not yet established as a general property. Please provide repeated measurements with statistical summaries and a precise description of the benchmark setup, or explicitly restrict the claim to the measured configuration.
  2. [Section 4] The paper notes that the compute method scales roughly linearly with the number of pixels per point while OpenGL scales better, and that the method is ideal only for point sizes of one pixel. This condition is absent from the abstract, where the speedup is presented without qualification. The abstract and conclusions should state that the claimed speedups are limited to one-pixel point rendering, and the 1% depth threshold used in the splatting pass (Section 2.2) should be justified or shown to be insensitive.
minor comments (4)
  1. [Section 1] The phrase 'features that may not be possible in the regular pipeline' is vague; please give a concrete example, such as the improved depth precision described in Section 2.1.
  2. [Section 2.1] The sentence 'we end up with 1 trillion mm = 1 billion m = 1 million km' is mathematically correct but stylistically awkward; consider rewriting for clarity.
  3. [References] The reference to Kenzel et al. has a typo: 'Kenzel et al . 2018' contains a space before the period; please correct it.
  4. [Section 2.1] The clear value 0xffffffffff000000 is not explained in the text; a brief description of its bit layout (40 bits of ones and 24 bits of zeros) would aid understanding.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper's claims are measured performance comparisons and a direct depth-encoding construction, not derived from or fitted to their own outputs.

full rationale

The paper makes two central claims: (1) a compute-shader rasterizer using atomicMin into a 64-bit framebuffer is up to 10x faster than GL_POINT rendering, and (2) it provides a 40-bit integer depth buffer with uniform or customizable precision. Neither claim is circular. The speedup is an empirical benchmark against an external OpenGL baseline: Table 1 reports measured rendering times for AtomicMin, Splatting, and GL_POINT on three models and two GPUs, and Section 3 explicitly quotes the 5.3x and 10x ratios from that table. The depth claim is a direct construction: depth is computed in double precision, multiplied by 1000, stored in a 40-bit field of a 64-bit integer, and written via atomicMin, with the encoding described in Section 2.1. There is no fitted parameter, no self-citation used as the load-bearing justification, and no equation that reduces to its own input. The known self-citations (Günther et al., Kenzel et al., Botsch et al.) motivate the approach or provide the splatting method but do not define the paper's contribution. The paper honestly discloses limitations: Section 3 notes that results vary with point order and viewpoint, and Section 4 states that the speed advantage holds mainly at one-pixel point sizes and may vanish past two pixels. Those caveats concern generalizability or benchmark representativeness, which are correctness risks, not circularity. The derivation chain is self-contained against external measurements, so the circularity score is 0.

Assumptions & free parameters 2 free parameters · 5 assumptions · 0 invented entities

The central claims rest on GPU atomic behavior, bit-packing arithmetic, and benchmark assumptions rather than on fitted constants. The only hand-chosen numeric threshold is the 1% splatting range; the 1000 scale factor sets the depth precision. No new physical entities are introduced.

free parameters (2)
  • splatting depth threshold = 1% of the closest depth in a pixel
    Section 2.2 merges fragments whose linear depth is at most 1% larger than the closest fragment. This percentage is chosen for scale invariance and is not derived from any quality metric.
  • depth scale factor = 1000 (millimeters per meter)
    Section 2.1 multiplies double-precision depth by 1000 to obtain integer millimeters, fixing the claimed 1 trillion mm range. It is a design choice that determines precision and range.
assumptions (5)
  • domain assumption atomicMin on 64-bit unsigned integers is available and executes atomically across threads on the target GPUs (Section 2.1).
    The closest-fragment write depends on atomicMin; if it were non-atomic or unavailable, the method would fail.
  • domain assumption All rendered depth values fit in the 40-bit field after scaling and shifting (Section 2.1).
    Depth is shifted 24 bits left into a 64-bit integer; values beyond 2^40 would corrupt the color bits or compare incorrectly. The paper only notes the range is sufficient for Earth-to-moon distances.
  • domain assumption High-quality surface splatting as described by Botsch et al. [2005] is a correct foundation for the averaging pass (Section 2.2).
    The compute-based splatting is presented as an implementation of the cited algorithm; the paper does not re-derive or validate its quality properties.
  • domain assumption The GL_POINT baseline in Table 1 is representative of the traditional approach (Section 3).
    The speedup claim depends on the baseline configuration, but no details are given for the OpenGL version, driver, point size, or viewpoint; the authors state results vary with point order and viewpoint.
  • standard math Packing depth in the high bits and color in the low bits makes atomicMin select the closest depth, with color only as a tie breaker (Section 2.1).
    This ordering property follows from the structure of 64-bit integers; the paper relies on it for correctness.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Rendering Point Clouds with Compute Shaders." pith.science (2026). https://pith.science/paper/6TDUZMZA

@misc{pith2026190802681,
  author       = {Pith},
  title        = {Pith review of: Rendering Point Clouds with Compute Shaders},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6TDUZMZA}},
  note         = {Machine review of arXiv:1908.02681}
}
read the original abstract

We propose a compute shader based point cloud rasterizer with up to 10 times higher performance than classic point-based rendering with the GL_POINT primitive. In addition to that, our rasterizer offers 5 byte depth-buffer precision with uniform or customizable distribution, and we show that it is possible to implement a high-quality splatting method that blends together overlapping fragments while still maintaining higher frame-rates than the traditional approach.

Figures

Figures reproduced from arXiv: 1908.02681 by the authors.

Figure 1
Figure 1. Point-based rendering via compute shaders. (b) Higher depth-precision. (c) Up to ten times faster than OpenGL [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

4 extracted references · 3 canonical work pages

  1. [2005]

    https://doi.org/10.1109/PBG.2005.194059 Christian M Günther, Thomas Kanzok, Lars Linsen, and Paul Rosenthal

    17–141. https://doi.org/10.1109/PBG.2005.194059 Christian M Günther, Thomas Kanzok, Lars Linsen, and Paul Rosenthal

    work page arXiv 2005

  2. [2013]

    Journal of WSCG 21 (2013), 153–161

    A GPGPU-based Pipeline for Accelerated Rendering of Point Clouds. Journal of WSCG 21 (2013), 153–161. Michael Kenzel, Bernhard Kerbl, Dieter Schmalstieg, and Markus Steinberger

    work page 2013

  3. [2015]

    (July 2015)

    Depth Precision Visualized. (July 2015). Retrieved May 8, 2018 from https://developer.nvidia.com/content/depth-precision-visualized 2

    work page 2015

  4. [2018]

    ACM Trans

    A High-performance Software Graphics Pipeline Architecture for the GPU. ACM Trans. Graph. 37, 4, Article 140 (July 2018), 15 pages. https://doi.org/10.1145/3197517. 3201374 Nathan Reed

    doi:10.1145/3197517 2018

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.