RadiusFPS-G: GPU-Accelerated Farthest Point Sampling

• RadiusFPS-G is a GPU-resident exact-FPS framework that reduces redundant distance evaluations and global memory traffic through spherical voxel pruning.
• It preserves standard FPS semantics by maintaining deterministic tie-breaking, hierarchical voxel indexing, and coordinate-wise skip tests for exact sample updates.
• Empirical results show 2–3× speedups over conventional GPU and QuickFPS baselines while lowering GPU memory usage in dense robotic perception workflows.

Searching arXiv for the RadiusFPS paper and closely related exact/accelerated FPS baselines. arxiv_search(query="RadiusFPS Efficient Farthest Point Sampling on CPUs and GPUs via Spherical Voxel Pruning", max_results=5) RadiusFPS-G is the GPU-resident realization of RadiusFPS, an exact-FPS-compatible acceleration framework for farthest point sampling in point-cloud pipelines. It is introduced in "RadiusFPS: Efficient Farthest Point Sampling on CPUs and GPUs via Spherical Voxel Pruning" (Yu et al., 4 Jun 2026) as a warp-level implementation that preserves the standard FPS update rule under the same initialization and tie-breaking policy while reducing redundant distance evaluations and global-memory movement. The method is motivated by robotic perception workloads in which LiDAR, RGB-D, and depth sensors generate dense point clouds, FPS is used to retain uniform geometric coverage for downstream segmentation, detection, mapping, and motion planning, and classical $O(NM)$ sampling becomes a dominant latency bottleneck.

1. Role in point-cloud perception

RadiusFPS-G addresses a specific systems problem: classical FPS repeatedly scans all $N$ points after each newly selected sample $s_j$, computes $\|p_i-s_j\|_2$, and updates the maintained nearest-sampled-point distance only if the new value is smaller. Repeating this over $M$ samples yields classical $O(NM)$ complexity. In robotic perception pipelines that process dense point clouds at over $10^6$ points per second, the cost of this update pattern can dominate end-to-end latency (Yu et al., 4 Jun 2026).

The reported profiling inside PointMetaBase makes the bottleneck explicit. FPS accounts for $77.6\%$ of sampling latency on S3DIS and $89.0\%$ on ScanNet, with latency growing sharply for large scenes. In such settings, downsampling is necessary for tractable downstream computation, but the downsampler itself can become the rate-limiting stage. RadiusFPS-G is therefore positioned not as a new sampling objective, but as an implementation and pruning framework that retains FPS-style geometric coverage while making that coverage practical under real-time and onboard-compute constraints.

This positioning also defines the comparison space. Vanilla CPU and GPU FPS preserve exactness but remain expensive; GPUs are not naturally aligned with the sequential outer loop of FPS, and naive GPU implementations still incur heavy global-memory traffic. FPGA accelerators such as MARS and PtrAcc obtain speedups through custom hardware pipelines, but those optimizations are not portable to commodity CPUs and GPUs. QuickFPS is treated as the strongest portable exact baseline, but with a substantial memory footprint that the paper regards as problematic for onboard deployment. RadiusFPS-G is proposed to reduce both arithmetic redundancy and memory movement without changing the standard FPS behavior under controlled initialization, precision, and deterministic tie-breaking.

2. Exact FPS semantics and hierarchical selection

The framework retains the standard incremental FPS rule. For an input point set $P=\{p_0,\dots,p_{N-1}\}\subset\mathbb{R}^3$, a sampled set $N$0, and current subset $N$1, the next sample is

$N$2

Rather than recomputing distances to all prior samples from scratch, RadiusFPS maintains

$N$3

updates

$N$4

and then selects

$N$5

RadiusFPS-G is designed to preserve this update semantics exactly, provided that all variants use the same initial seed, the same floating-point precision, and deterministic tie-breaking in which $N$6 returns the point with the smallest original input index when multiple candidates have identical distances (Yu et al., 4 Jun 2026).

To support pruning and efficient search, the point cloud is indexed by active voxels. Only nonempty voxels are retained, producing active voxels $N$7. For each active voxel $N$8, the framework stores the point indices it contains, its voxel center $N$9, and a voxel-level bound

$s_j$0

This representation enables a two-level search that is still equivalent to global FPS. RadiusFPS first selects the best voxel,

$s_j$1

and then selects the farthest point inside that voxel,

$s_j$2

Because $s_j$3 is defined as the maximum point-level distance within voxel $s_j$4, this hierarchical procedure is equivalent to the global $s_j$5 rule under the same deterministic tie-breaking policy. The significance is that RadiusFPS-G changes the execution strategy of search and update, not the mathematical selection criterion.

3. Spherical voxel pruning and coordinate-wise skipping

The central pruning mechanism is spherical voxel pruning. The point cloud is enclosed in an axis-aligned bounding box with $s_j$6, $s_j$7, and side lengths $s_j$8. After slight expansion by $s_j$9, voxel side length is set by a voxel-count resolution $\|p_i-s_j\|_2$0. Each point is mapped to voxel coordinates, and only active voxels are retained.

Each cubic voxel is conservatively enclosed by a sphere of radius

$\|p_i-s_j\|_2$1

This matters because a centroid-only voxel test is unsafe for exact FPS: $\|p_i-s_j\|_2$2 is not itself a lower bound on $\|p_i-s_j\|_2$3. Exact pruning requires a bound $\|p_i-s_j\|_2$4 such that

$\|p_i-s_j\|_2$5

Using the triangle inequality, the paper defines

$\|p_i-s_j\|_2$6

which satisfies

$\|p_i-s_j\|_2$7

This yields the exact voxel-pruning rule

$\|p_i-s_j\|_2$8

If the inequality holds, then for every point in the voxel the new sample cannot produce a strict improvement over the stored nearest-sampled-point distance, so the entire voxel can be skipped without changing $\|p_i-s_j\|_2$9, subsequent $M$0, or future sample selection (Yu et al., 4 Jun 2026).

Voxel pruning is complemented by a point-level skip test for voxels that survive the coarse bound. Since

$M$1

a point can be skipped if any coordinate difference already exceeds the current nearest-sample distance:

$M$2

Only points that fail this test require the exact Euclidean update. The framework therefore combines voxel-level lower-bound pruning with coordinate-wise point filtering: the former removes whole regions, and the latter removes residual unnecessary square, sum, and square-root work inside surviving voxels.

A common misconception is that point skipping alone is the method. The paper treats that as incorrect. The ablation showing “point skip only” is presented as an unguided negative control, and the interpretation is that point skip must operate within the synchronized RadiusFPS framework rather than as an independent heuristic.

4. GPU execution model and fused kernels

RadiusFPS-G is the hardware-oriented implementation of this framework on GPU. Its distinctive claim is not new pruning mathematics, but a warp-level execution strategy that fuses voxel selection, pruning, and distance update into memory-coalesced kernels while keeping intermediates in registers and shared memory instead of repeatedly materializing them in global memory. The paper states that RadiusFPS-G “fuses voxel selection, pruning, and distance update into memory-coalesced kernels, eliminating costly global-memory round-trips” (Yu et al., 4 Jun 2026).

The preprocessing pipeline is entirely GPU-resident. Each point computes a flattened voxel id,

$M$3

while retaining its original index $M$4. A parallel radix sort groups points with the same voxel id into contiguous memory. The implementation then applies an AoS-to-SoA transformation, storing coordinates as

$M$5

so that warps can fetch $M$6, $M$7, and $M$8 through coalesced memory transactions. Active voxels are compacted through parallel unique, and each active voxel stores compact offsets $M$9 and counts $O(NM)$0, defining a compact point segment $O(NM)$1. Initial global distances to the seed point are computed in parallel, and voxel bounds are initialized by a per-voxel block reduction.

Fusion Kernel 1 performs farthest-point selection as a fused two-level reduction. It first reads $O(NM)$2 and performs a block-level argmax to find the voxel with maximal bound. The reduction is warp-centric: each thread carries a pair $O(NM)$3, with the negated original index encoding deterministic smallest-index tie-breaking. Warp shuffle-down intrinsics combine candidates, each warp writes a partial maximum to shared memory, and Warp 0 performs the final reduction. The same kernel then immediately reduces over the compact point segment of the selected voxel using $O(NM)$4, again with original-index tie-breaking, and writes the chosen sample directly to global memory. The best-voxel result is therefore not round-tripped through host code or extra kernels.

Fusion Kernel 2 handles updates with a one-block-to-one-voxel mapping. Each block loads the newly selected sample $O(NM)$5 and voxel metadata into shared memory, evaluates the same spherical pruning rule $O(NM)$6, and exits early if the voxel can be pruned. If not, threads iterate over the points in the voxel’s compact segment in a strided pattern, fetch coordinates from the SoA layout, apply the coordinate-wise skip test, and compute the exact Euclidean distance only when necessary. The updated value

$O(NM)$7

is written back only if it improves the stored distance. Each thread tracks a local maximum, and a block reduction updates the voxel bound $O(NM)$8. The block thus performs coarse pruning, fine-grained updates, and voxel-bound synchronization before returning.

The execution organization is explicit even though exact thread and block dimensions are not reported. RadiusFPS-G uses warp-level reductions inside a block; Warp 0 performs second-stage reduction over per-warp partials; Fusion Kernel 2 maps one block to one active voxel; shared memory stores sampled-point data, voxel metadata, and reduction intermediates; registers store per-thread local maxima and reduction values. After initial GPU transfer and voxelization, the architectural diagram states that “the only synchronization point between these kernels is the acquisition of the next sampled point in each iteration.”

5. Empirical behavior, scaling, and downstream integration

The experimental evaluation uses S3DIS, ScanNet, and SemanticKITTI, integrated into OpenPoints with PointMetaBase and PointVector backbones. Hardware is an Intel i7-12700KF CPU and an NVIDIA RTX 6000 Ada GPU running Ubuntu 24.04 and CUDA 11.6. Metrics are end-to-end runtime over validation scenes together with OA and mIoU (Yu et al., 4 Jun 2026).

On PointMetaBase, RadiusFPS-G reports $O(NM)$9 OA and $10^6$0 mIoU on S3DIS with runtime $10^6$1 s; $10^6$2 OA and $10^6$3 mIoU on ScanNet with runtime $10^6$4 s; and $10^6$5 OA and $10^6$6 mIoU on SemanticKITTI with runtime $10^6$7 s. Relative to GPU FPS on the same model, runtimes change from $10^6$8 to $10^6$9 s on S3DIS, from $77.6\%$0 to $77.6\%$1 s on ScanNet, and from $77.6\%$2 to $77.6\%$3 s on SemanticKITTI, corresponding to about $77.6\%$4, $77.6\%$5, and $77.6\%$6 speedups. Relative to QuickFPS, RadiusFPS-G is also faster on all three PointMetaBase benchmarks: $77.6\%$7 versus $77.6\%$8 s on S3DIS, $77.6\%$9 versus $89.0\%$0 s on ScanNet, and $89.0\%$1 versus $89.0\%$2 s on SemanticKITTI.

On PointVector, RadiusFPS-G reports $89.0\%$3 OA and $89.0\%$4 mIoU on S3DIS with runtime $89.0\%$5 s; $89.0\%$6 OA and $89.0\%$7 mIoU on ScanNet with runtime $89.0\%$8 s; and $89.0\%$9 OA and $P=\{p_0,\dots,p_{N-1}\}\subset\mathbb{R}^3$0 mIoU on SemanticKITTI with runtime $P=\{p_0,\dots,p_{N-1}\}\subset\mathbb{R}^3$1 s. Against GPU FPS, the runtimes are reduced from $P=\{p_0,\dots,p_{N-1}\}\subset\mathbb{R}^3$2 to $P=\{p_0,\dots,p_{N-1}\}\subset\mathbb{R}^3$3 s on S3DIS, $P=\{p_0,\dots,p_{N-1}\}\subset\mathbb{R}^3$4 to $P=\{p_0,\dots,p_{N-1}\}\subset\mathbb{R}^3$5 s on ScanNet, and $P=\{p_0,\dots,p_{N-1}\}\subset\mathbb{R}^3$6 to $P=\{p_0,\dots,p_{N-1}\}\subset\mathbb{R}^3$7 s on SemanticKITTI, or about $P=\{p_0,\dots,p_{N-1}\}\subset\mathbb{R}^3$8, $P=\{p_0,\dots,p_{N-1}\}\subset\mathbb{R}^3$9, and $N$00. Against QuickFPS, RadiusFPS-G remains faster: $N$01 versus $N$02 s on S3DIS, $N$03 versus $N$04 s on ScanNet, and $N$05 versus $N$06 s on SemanticKITTI.

The paper also separates sampling-only scalability from end-to-end results. In a large S3DIS room, RadiusFPS-G reaches up to $N$07 speedup over vanilla GPU FPS when voxel resolution is tuned, whereas end-to-end improvements are smaller because the rest of the network is unchanged. The abstract summarizes the practical envelope as up to $N$08 speedup over GPU-based FPS, with RadiusFPS-G matching or exceeding QuickFPS among the evaluated methods while using roughly half its GPU memory. In the large-room scalability discussion, QuickFPS peaks near $N$09 MB while RadiusFPS-G uses about $N$10 MB. Throughput is reported as consistently highest for RadiusFPS-G.

The ablation study isolates the impact of kernel fusion. On S3DIS, taking GPU FPS as the $N$11 baseline, RadiusFPS-G with both fusion kernels reaches $N$12 total speedup; using only Fusion Kernel 1 yields $N$13; using only Fusion Kernel 2 yields $N$14; and using neither yields $N$15. All of these RadiusFPS-G variants retain $N$16 mIoU, which supports the interpretation that the fusion kernels are implementation optimizations rather than approximations.

Downstream accuracy is generally preserved closely. In the dedicated sampling-quality table, RadiusFPS-G is competitive with or slightly above GPU FPS on PointMetaBase for S3DIS ($N$17 versus $N$18) and ScanNet ($N$19 versus $N$20), and close on SemanticKITTI ($N$21 versus $N$22). On PointVector it remains close: $N$23 versus $N$24 on S3DIS, $N$25 versus $N$26 on ScanNet, and $N$27 versus $N$28 on SemanticKITTI. This contrasts with approximation baselines such as FPS+NPDU, which can collapse to $N$29 mIoU on SemanticKITTI with PointVector.

Integration with FastPoint extends the systems argument. FastPoint is a learned sampler that predicts the FPS-like sampling trajectory after using early FPS samples as priors, and RadiusFPS-G accelerates that bootstrapping stage. The combined configurations are the fastest end-to-end pipelines in the paper. On SemanticKITTI with PointMetaBase, runtimes are $N$30 s for FastPoint + FPS, $N$31 s for FastPoint + QuickFPS, $N$32 s for FastPoint + RadiusFPS, and $N$33 s for FastPoint + RadiusFPS-G. On S3DIS with PointMetaBase, FastPoint + RadiusFPS-G reaches $N$34 s total runtime versus $N$35 s for the GPU FPS baseline. The speedup figure reports sampling speedups up to $N$36 for FastPoint + RadiusFPS-G and total pipeline speedups up to roughly $N$37. The paper also reports an accuracy trade-off when FastPoint is used; on SemanticKITTI with PointMetaBase, FastPoint + RadiusFPS-G gives $N$38 mIoU versus $N$39 for GPU FPS, an absolute drop of about $N$40 points.

6. Exactness conditions, limitations, and adjacent directions

RadiusFPS-G is presented as exact-FPS-compatible rather than approximate. Its correctness rests on conservative pruning and on the equivalence between voxel-level and global selection. Exact agreement with standard FPS, however, depends on three explicit conditions: the same initialization, the same floating-point precision, and deterministic tie-breaking. The hierarchical selection strategy makes tie-breaking especially important, and the implementation encodes smallest-index resolution explicitly through the pair $N$41. Different numerical precision or unresolved ties can produce different, though still valid, FPS sequences (Yu et al., 4 Jun 2026).

Voxelization parameters affect efficiency but not correctness, because the lower bounds are conservative. Changing the voxel-count resolution $N$42 changes how much pruning occurs, not the validity of the update rule. Empirically, the effectiveness of pruning increases later in sampling because many points already have nearby representatives; the paper states that over $N$43 of updates become ineffective in later iterations. The scalability study further indicates that larger, denser scenes benefit more, and that CPU performance is more sensitive to voxel resolution than GPU performance. On GPU, RadiusFPS-G is described as relatively insensitive to the voxel parameter $N$44, whereas on CPU the optimal $N$45 depends on scene structure.

The method also has visible limits. Benefits may be smaller on small point clouds, where launch overhead and indexing overhead dominate. Worst-case pruning can be weak on adversarial or highly unstructured point sets. Very fine voxelization can add indexing overhead and cache penalties, while overly coarse voxelization weakens pruning. The implementation is tuned for CUDA-style warp operations, shuffle-down reductions, shared memory, block reductions, radix sort, and memory-coalesced SoA layouts, and the paper does not claim full portability across GPU vendors. These are constraints of realization rather than of the pruning logic itself.

An adjacent research direction is hardware acceleration for repeated fixed-radius queries on RT cores. "Advancing RT Core-Accelerated Fixed-Radius Nearest Neighbor Search" (Meneses et al., 22 Jan 2026) is not an FPS paper, but it shows that dynamic BVH management, on-the-fly accumulation without explicit neighbor lists, and periodic-domain query transformations can materially improve repeated radius-query workloads on GPU. This suggests a broader systems context for RadiusFPS-G: spherical-voxel pruning is one route to reducing repeated geometric work in point-cloud processing, while RT-core BVH traversal is another. A plausible implication is that future radius-based sampling, pruning, or graph-construction pipelines may combine conservative algorithmic bounds of the RadiusFPS type with specialized traversal hardware when the workload is dominated by repeated local geometric queries.

RadiusFPS-G is therefore best understood as an exact-FPS-compatible GPU sampler that attacks the two main inefficiencies of classical FPS: redundant distance updates and excessive memory traffic. Its importance lies less in altering the sampling objective than in making standard FPS behavior substantially cheaper in realistic robotic vision pipelines, while remaining close to vanilla FPS in memory usage and markedly lighter than QuickFPS.