GLASS: Architecture-Tuned, Composable, Device-Side Linear Algebra for Edge Robotics and Beyond

I. INTRODUCTION

• GPU robotics lacks a reusable numerical layer comparable to CPU libraries, leaving systems to mix approaches or repeatedly build low-level code.The paper notes that GPU robotics relies on diverse frameworks, libraries, and bespoke code, creating overhead and duplication.Source: §I · p. 1
• Shared numerical infrastructure could amortize optimization, validation, and maintenance as AI tools make code cheaper to produce but not to validate or maintain.The authors note that GPU code is prone to subtle errors and continuous testing can be expensive.Source: §I · p. 1
• GLASS unifies thread-, warp-, block-, and NVIDIA-backed robotics-scale numerical primitives under an open-source, header-only CUDA C++ device API.Its measured implementation choice, execution scope, and launch packing are architecture-specific and resolved at compile time.Source: §I · p. 1
• Best and worst placements differ by a median 4.9× (maximum 81×), while GLASS beats the best of PyTorch and JAX by up to 73× on Orin and 12× on RTX 5090.The authors also report that 145 of 396 recommended placements change between Orin and RTX 5090, and 162 of 396 versus AGX Xavier.Source: §I · p. 1
• Robotics integrations exposed a pre-existing numerical bug and improved embedded runtimes by up to 1.5×.GLASS also provides independent numerical oracles and source-bound GPU test attestation.Source: §I · p. 1

A. CPU and GPU Numerical Libraries

• GPU options range from host-dispatched libraries and frameworks to device-callable routines, but JAX and PyTorch operations cannot be embedded inside application kernels.MathDx, CUB, and CUTLASS move more computation inside user kernels; Kokkos Kernels and CUDA-executable Eigen operations provide other composable options.Source: A. CPU and GPU Numerical Libraries · p. 2
• GLASS integrates existing device libraries as candidate backends and automatically tunes execution scope and launch packing for each target architecture.It saves the selected setup as a reusable configuration rather than seeking to replace those libraries.Source: A. CPU and GPU Numerical Libraries · p. 2

B. Performance Portability and Validation

• GLASS applies measurement-based adaptation to execution placement inside GPU kernels, following earlier measurement-based approaches such as ATLAS, FFTW, and OSKI.Other cited systems instead generate or search for specialized code.Source: B. Performance Portability and… · p. 2
• GLASS uses independent numerical oracles and carries source-bound, low-cost local-GPU test results into CPU-only continuous integration.The validation design responds to concerns that generated GPU-kernel performance can depend strongly on the correctness oracle used.Source: B. Performance Portability and… · p. 2

III. DESIGN

• GLASS provides composable device-side primitives for robotics-scale linear algebra and geometric computation.The library is header-only CUDA C++.Source: §III · p. 2
• Application kernels call GLASS primitives directly, keeping numerical operations inside the surrounding GPU computation.This avoids additional host calls, kernel launches, and data marshalling.Source: §III · p. 2
• The library is designed for the small- to medium-sized batched computations common in robotics.Source: §III · p. 2

A. Programming Model and Execution Interfaces

• GLASS supports block-, warp-, and thread-scoped interfaces alongside optional NVIDIA-backed wrappers, with shared mathematical conventions and data layouts.The wrappers use CUB collectives, cuBLASDx matrix operations, and cuSOLVERDx factorizations and solves where available.Source: A. Programming Model and Execution… · p. 2
• Offline autotuning stores architecture-specific implementation choices, which compile-time constexpr tables apply without host dispatch or runtime overhead.The autotuning benchmarks the library on the target GPU.Source: A. Programming Model and Execution… · p. 3
• The compile-time advisor recommends execution scope and launch packing because changing from one problem per block to warp or thread execution changes application launch geometry and indexing.On Orin for fp32 POSV, it recommends thread scope at N=8 and NVIDIA block scope at N=32.Source: A. Programming Model and Execution… · p. 3
• GLASS targets problems small enough for one CUDA block; larger cross-block dense problems are generally better served by conventional host-dispatched libraries.Implementations are instantiated only when their compile-time size and resource requirements are feasible.Source: A. Programming Model and Execution… · p. 3

B. Numerical and Robotics Primitives

• GLASS covers BLAS/LAPACK, structured solvers, and robotics geometry while fixing operation conventions and testing them against independent references or defining identities.Shared interfaces also let higher-level operations reuse primitives and retain intermediates on chip; fused operations include an optimized Riccati gain implementation.Source: B. Numerical and Robotics Primitives · p. 3

C. Validation and Continuous Testing

• Numerical correctness is checked against independent NumPy and SciPy references, Pinocchio where applicable, and identities, residuals, equivalences, or finite differences when no direct reference exists.Tests also cover numerical scale, conditioning, layouts, and execution scopes when these are part of the documented contract.Source: C. Validation and Continuous Testing · p. 3
• A pytest plugin records the exact source tree and local-GPU test outcomes, then signs evidence that CPU-only CI can verify without rerunning the GPU suite.The receipts are signer attestations, not proof that a claimed GPU executed the tests; trusted signer subsets can raise confidence.Source: C. Validation and Continuous Testing · p. 3

IV. EVALUATION

• The evaluation asks five questions spanning device-side capabilities, architecture dependence, host-library and framework comparisons, robotics-specific composition, and replacement of bespoke code in real systems.The supplied passage states the questions, not their answers.Source: §IV · p. 3

A. Methodology

• Workloads span B = 1–8192 and N = 4–128, from single-problem low-latency execution to heavily batched workloads, across Orin, Xavier, and RTX 5090 platforms.The Orin is the primary test platform; the Xavier provides an older-generation edge comparison and the RTX 5090 tests scaling to a desktop GPU.Source: A. Methodology · pp. 3–4
• Placement sweeps cover six operations, eleven sizes, three batch regimes, and fp32/fp64; NVIDIA supports only 357 of 396 Orin cells, 354 on RTX 5090, and none on Xavier.NVIDIA placements are selected only when more than 5% faster, the dispatch margin used to account for measurement noise.Source: A. Methodology · p. 4

B. Performance Against Device-Side Libraries

• 4.9× median and up to 81× separate the best and worst placements; native GLASS wins 99 of 195 comparable fp32 Orin cells, with a 2.1× geometric-mean win and a 22.1× maximum.NVIDIA paths are selected or within the dispatch margin in 96 of 195 cells; on the RTX 5090, their share rises to 64%, while the maximum native win is 3.9×.Source: B. Performance Against Device-Side… · p. 4
• GLASS wins 119 of 162 cells against Kokkos Kernels, while Eigen wins 26 of 126 against GLASS thread implementations, GLASS wins 36, and 64 tie.The GLASS–Eigen median runtime ratio is 1.00×; Fig. 3 covers limited matched supported operations on the Orin.Source: B. Performance Against Device-Side… · p. 4, Figure 3 · p. 4
• GLASS’s advantage comes from its broader placements and numerical primitives, and is most important for deployable robotics-scale edge devices.This is the authors’ overall conclusion from the device-side comparisons.Source: B. Performance Against Device-Side… · p. 4
• The NVIDIA warp tier is omitted from Figure 2 and the remaining experiments because its backend is exposed only via CUB reductions, which fall within the dispatch margin in 121 of 126 cells (96%).Source: B. Performance Against Device-Side… · p. 4

C. Architecture Adaptation

• Threads remain effective for many small factorizations and solves, while warp, block, and NVIDIA-backed implementations take over in different problem-size and batch-size regions.The qualitative trends persist across architectures, but their boundaries move substantially.Source: C. Architecture Adaptation · p. 5
• Orin placements differ from the RTX 5090 in 145/396 cells and from the Xavier in 162/396, with many changes remaining among common native backends.Among common candidates, 107/396 RTX–Orin, 94/396 RTX–Xavier, and 66/396 Orin–Xavier placements still change.Source: C. Architecture Adaptation · p. 5
• Cross-architecture reuse adds 4–20% geometric-mean runtime, with 95th-percentile penalties reaching 2.59×; Jetson-to-RTX transfers cost 20% on average.Figure 5 reports transfer penalties relative to the locally tuned target plan.Source: C. Architecture Adaptation · p. 5, Figure 5 · p. 5
• Reducing Orin power from 50 W to 30 W and 15 W raises geometric-mean runtime by 29% and 91%, respectively, yet changes only 9 of 396 placement decisions in each mode.The same placement table can be reused across power modes, although lower power reduces absolute throughput.Source: C. Architecture Adaptation · p. 5
• Generating a placement table is a one-time offline operation for each architecture and toolchain configuration; tuning sweeps took 5.5 hours on Orin, 9 hours on Xavier, and 2 hours on RTX 5090.Source: C. Architecture Adaptation · p. 5

D. Performance Against Host-Batched Libraries and Compiler Frameworks

• GLASS is faster than the per-cell best of PyTorch and JAX in 359 of 378 Orin cells, with per-operation geometric means of 4.3–9.5× and dispatch-bound cells reaching 73×.The framework baselines use device-resident inputs and outputs plus pre-compiled and jitted code.Source: D. Performance Against Host-Batched… · p. 6
• On Orin, GLASS beats host-dispatched cuBLAS/cuSOLVER at every measured batch size through N = 64 for POSV (up to 113.9×), N = 48 for GEMM (up to 12.1×), and N = 24 for POTRF (up to 12.8×).Both baseline families pay per-call dispatch overhead, most heavily in the small-matrix regime GLASS targets.Source: D. Performance Against Host-Batched… · p. 6
• On RTX 5090, GLASS leads frameworks in 320 of 378 cells at geometric means of 1.5–2.6×, up to 12×; on Xavier, it reaches up to 89.3× against cuBLAS/cuSOLVER.Host cuSOLVER retakes portions of larger standalone Cholesky, and PyTorch/JAX wins for the largest GEMM N-and-B combination; MAGMA performs best on workstation but is out of reach for embedded deployments.Source: D. Performance Against Host-Batched… · p. 6

E. Robotics Operations and Composition

• Best fine-grained placement improves throughput by 3.5–9.7× over whole-block execution on Orin and 1.7–5.0× on RTX 5090 across representative robotics operations.Thread execution wins most cases, while reduction-heavy fp32 softmax favors a warp.Source: E. Robotics Operations and Composition · p. 6, Table II · p. 6
• For LQR feedback gain, fusion is up to 1.75× faster through B = 64, but unfused composition wins by up to 2.9× at larger batches and for register-heavier fp64 shapes almost everywhere.Independent per-primitive kernels can occupy the GPU more fully than a fused kernel constrained by shared-memory footprint.Source: E. Robotics Operations and Composition · pp. 6–7

F. Case Studies in Published Robotics Systems

• In sampling-based MPC [9], replacing application-specific reductions with GLASS preserved the surrounding algorithm and interface, exposed a pre-existing non-minimal baseline bug, and produced 1.21–1.50× Orin speedups across 128–8192 rollouts.The independent double-precision reference identified the error, and the repair was accepted upstream; RTX 5090 speedups were 1.21–1.46×.Source: F. Case Studies in Published Robotics… · p. 7
• In a batched inverse-kinematics solver, GLASS reduced specialized device numerics from approximately 355 lines to 29 lines of application code, a 92% reduction.A 201-line warp Cholesky implementation became glass::warp::posv.Source: F. Case Studies in Published Robotics… · p. 7
• At batch size 2,000, GLASS reduced Orin runtime from 9.94 ms to 7.92 ms, a 1.26× speedup; the corresponding RTX 5090 improvement was 1.02×.Source: F. Case Studies in Published Robotics… · p. 7

• Across three GPU architectures, no implementation family dominates, and transferring placements between architectures adds 4–20% geometric-mean runtime.Source: §V · p. 7
• Downstream integrations exposed latent correctness errors and improved embedded runtimes by up to 1.5x.Source: §V · p. 7
• Future work includes provably correct reduced- and mixed-precision support and broader factorization support.Source: §V · p. 7
• The authors plan community-contributed architecture tables and support for non-NVIDIA accelerators, while noting the design also applies to other domains.Source: §V · p. 7