TBD-GPU: Diverse GPU-Centric Frameworks

• TBD-GPU is a polysemous term defining multiple GPU-accelerated frameworks across distinct domains such as DNN benchmarking, electronic structure, numerical solvers, and real-time management.
• Its implementations include a GPU-accelerated ML tight-binding framework that uses descriptor-based Hamiltonian assembly and LSQT to efficiently compute electronic properties at scale.
• Additional variants cover a block-tridiagonal solver leveraging batched dense kernels for accelerated linear algebra and a server-based method for predictable GPU access in real-time systems.

TBD-GPU is not a single standardized term in the arXiv literature. Instead, it denotes several distinct GPU-centered research artifacts and methodological lines: a GPU-accelerated machine-learning tight-binding framework for device-scale electronic-property calculations, an open-source GPU solver for symmetric positive definite block-tridiagonal systems, and a server-based method for predictable GPU access in real-time systems. A related but distinct antecedent is TBD, the “Training Benchmark for DNNs,” which established a GPU-centric benchmark and profiling methodology for deep neural network training rather than a framework named “TBD-GPU” in the narrow sense (Zhu et al., 2018, Wang et al., 8 Sep 2025, Jin et al., 3 Sep 2025, Kim et al., 2017).

1. Terminological scope and disambiguation

In the cited literature, the designation spans multiple technical domains rather than a single software stack or canonical architecture. This suggests that “TBD-GPU” should be treated as a context-dependent label whose meaning is determined by the surrounding application area.

Usage	Domain	Core definition
TBD benchmark	DNN training systems	A benchmark and analysis toolchain for DNN training
TBD-GPU / GPUTB	Electronic structure and transport	A GPU-accelerated ML tight-binding framework with CUDA LSQT
TBD-GPU solver	Numerical linear algebra	An open-source GPU solver for SPD block-tridiagonal systems
TBD-GPU management	Real-time systems	A server-based approach for predictable GPU access

The DNN-training benchmark emphasizes GPU utilization, FP32 utilization, memory footprint, and distributed communication in training workloads across TensorFlow, MXNet, and CNTK (Zhu et al., 2018). The electronic-structure usage denotes a framework that learns environment-dependent tight-binding Hamiltonians and computes DOS and transport with CUDA LSQT on GPUs (Wang et al., 8 Sep 2025). The linear-algebra usage denotes a recursive Schur-complement solver mapped onto batched BLAS/LAPACK kernels on CUDA and ROCm (Jin et al., 3 Sep 2025). The real-time usage denotes a highest-priority GPU server that handles requests on behalf of tasks to bound waiting time and avoid busy-waiting (Kim et al., 2017).

2. GPU-centric benchmarking antecedent: TBD for deep neural network training

The 2018 TBD benchmark was introduced to counter a narrow emphasis on inference-only and image-classification-only evaluation. It covers image classification, machine translation, speech recognition, object detection, adversarial networks, and reinforcement learning, with eight state-of-the-art models across TensorFlow, MXNet, and CNTK. The experimental stack used Ubuntu 16.04, TensorFlow v1.3, MXNet v0.11.0, CNTK v2.0, CUDA 8, and cuDNN 6, on a 16-node cluster with 28-core Intel Xeon E5-2680 processors and one to four NVIDIA Quadro P4000 GPUs per node, with additional sensitivity experiments on NVIDIA Titan Xp (Zhu et al., 2018).

A central contribution was a GPU-focused measurement methodology. GPU compute utilization was defined as

$$\text{GPU utilization} = (\text{GPU active time} / \text{total elapsed time}) \times 100\%,$$

FP32 utilization as

$$\text{FP32 utilization} = (\text{actual FP32 flop count during active time } T) / (\text{FLOPS}_{\text{peak}} \times T) \times 100\%,$$

and CPU utilization as

$$\text{CPU utilization} = [\text{sum over cores of active time}] / (\text{core\_count} \times \text{total elapsed time}) \times 100\%.$$

To reason about scaling and bottlenecks, iteration time was decomposed as

$$T_{\text{total}} = T_{\text{compute}} + T_{\text{comm}} + T_{\text{io}} + T_{\text{overhead}},$$

with communication modeled by

$$T_{\text{comm}} \approx \text{bytes}_{\text{transferred}} / \text{bandwidth} + \text{latency} \times \text{message}_{\text{count}},$$

and ring-allreduce approximated by

$$T_{\text{ring}} \approx 2 \times (N-1)/N \times (\text{bytes}/\text{bandwidth}) + 2 \times (N-1) \times \text{latency}.$$

The benchmark also introduced publicly available per-framework GPU memory profilers that break memory into weights, gradients, activations, workspace, and dynamic allocations:

$$M_{\text{total}} = M_{\text{weights}} + M_{\text{activations}} + M_{\text{gradients}} + M_{\text{workspace}} \; (+ M_{\text{dynamic}} \text{ where applicable}).$$

The reported breakdowns showed that feature maps dominate training memory, accounting for 70–90% of total memory in most models, including approximately 89% in ResNet-50 and Sockeye and approximately 62% in Deep Speech 2. The benchmark therefore shifted attention from parameter storage to activation pressure, workspace tradeoffs, and the saturation behavior of GPU utilization and FP32 utilization as batch size increases (Zhu et al., 2018).

Several representative empirical observations illustrate the methodology’s scope. Faster R-CNN at batch size 1 reached 2.3 images/sec on both TensorFlow and MXNet, with GPU compute utilization of approximately 89.4% and 90.3%, and FP32 utilization of approximately 58.9% and 70.9%, respectively. TensorFlow Seq2Seq reached approximately 365 samples/sec at batch size 128 on an 8 GB P4000, whereas MXNet Sockeye fit batch size 64 and achieved approximately 229 samples/sec. CNNs such as ResNet-50 and Inception-v3 approached approximately 95% or higher GPU compute utilization at larger batch sizes, but throughput gains saturated; Inception-v3, for example, saw less than 10% throughput improvement from batch 16 to 32. CPU utilization was typically below 15%, often below 8%, and batch-normalization kernels were identified as a hotspot, with cuDNN kernels such as bn_bw_1C11_kernel_new and bn_fw_tr_1C11_kernel_new consuming approximately 5–10% of GPU time at approximately 30–46% FP32 utilization (Zhu et al., 2018).

3. TBD-GPU as a GPU-accelerated machine-learning tight-binding framework

In electronic-structure theory, TBD-GPU denotes the framework reported as GPUTB: a GPU-accelerated tight-binding machine-learning method designed to map atomic structure to electronic structure efficiently while retaining transferability across basis sets, exchange-correlation functionals, allotropes, and finite-temperature disorder. Its starting point is an orthogonal tight-binding Hamiltonian on an LCAO basis,

$$H = \sum_i \epsilon_i c_i^{\dagger} c_i + \sum_{i\neq j} t_{ij} c_i^{\dagger} c_j + h.c.,$$

with environment-dependent onsite and hopping terms learned as

$$\epsilon_i = f_\epsilon(\mathbf{D}_i; \theta), \qquad t_{ij} = f_t(\mathbf{D}_{ij}; \phi).$$

In the reported implementation, $f_\epsilon$ and $$\text{FP32 utilization} = (\text{actual FP32 flop count during active time } T) / (\text{FLOPS}_{\text{peak}} \times T) \times 100\%,$$0 are MLPs driven by MPNN descriptors, while hopping is assembled in Slater–Koster form through directional angular factors $$\text{FP32 utilization} = (\text{actual FP32 flop count during active time } T) / (\text{FLOPS}_{\text{peak}} \times T) \times 100\%,$$1 and an environment modulation term (Wang et al., 8 Sep 2025).

The descriptor construction uses radial expansions with Chebyshev polynomials and smooth cutoffs. Node features are aggregated over neighbors, edge features combine cutoff-weighted local environments, and angular dependence is delegated to Slater–Koster factors. According to the paper, this design ensures translation and permutation invariance through radial descriptors and neighborhood aggregation, while rotational covariance is enforced at the operator level through the angular factors. The model is trained directly against band eigenvalues with

$$\text{FP32 utilization} = (\text{actual FP32 flop count during active time } T) / (\text{FLOPS}_{\text{peak}} \times T) \times 100\%,$$2

using band-wise weights, AdamW, batch normalization, L2 regularization, and a band-expansion curriculum from low to higher bands; convergence is judged by sub-1% MAE change over 50 epochs (Wang et al., 8 Sep 2025).

Representative accuracy figures establish the framework’s intended regime. For SiGe with $$\text{FP32 utilization} = (\text{actual FP32 flop count during active time } T) / (\text{FLOPS}_{\text{peak}} \times T) \times 100\%,$$3, $$\text{FP32 utilization} = (\text{actual FP32 flop count during active time } T) / (\text{FLOPS}_{\text{peak}} \times T) \times 100\%,$$4, and $$\text{FP32 utilization} = (\text{actual FP32 flop count during active time } T) / (\text{FLOPS}_{\text{peak}} \times T) \times 100\%,$$5 channels, cutoff radius approximately 5 Å, and up to third neighbors, the reported MAE was 13.0 meV for 8 atoms, 19.5 meV for 64 atoms, and 16.7 meV for 216 atoms, with generalization across supercells without retraining. In cross-material benchmarks against DeePTB, the average MAE was 0.018 eV for GPUTB versus 0.036 eV for DeePTB across diamond, GaP, AlAs, and phase-transfer tests. For graphene at 300 K, the MAE was 25.8 meV on sampled configurations used to build the 6.5-million-atom transport model. For h-BN/graphene heterojunctions, the model reproduced unit-cell symmetry-breaking gap opening and yielded large-scale DOS with narrow gaps of approximately 0.035–0.044 eV (Wang et al., 8 Sep 2025).

Its GPU realization is split between PyTorch and CUDA. Descriptor generation, message passing, and Hamiltonian assembly are implemented with PyTorch on GPUs, while LSQT—including KPM, stochastic trace, and velocity autocorrelation—is implemented in pure CUDA, integrating and optimizing the open-source GPUQT lineage. The sparse orthogonal Hamiltonian is stored in compressed row-like formats with neighbor-sorted adjacency lists for coalesced memory access; threads map to orbitals or edges, warps to contiguous rows, shared memory caches neighbor lists and Slater–Koster angular factors, and descriptor MLPs are run batched over atoms and edges. Descriptor generation and Hamiltonian assembly scale as $$\text{FP32 utilization} = (\text{actual FP32 flop count during active time } T) / (\text{FLOPS}_{\text{peak}} \times T) \times 100\%,$$6, with $$\text{FP32 utilization} = (\text{actual FP32 flop count during active time } T) / (\text{FLOPS}_{\text{peak}} \times T) \times 100\%,$$7 the average neighbor count under $$\text{FP32 utilization} = (\text{actual FP32 flop count during active time } T) / (\text{FLOPS}_{\text{peak}} \times T) \times 100\%,$$8, while LSQT propagation scales as $$\text{FP32 utilization} = (\text{actual FP32 flop count during active time } T) / (\text{FLOPS}_{\text{peak}} \times T) \times 100\%,$$9 for $$\text{CPU utilization} = [\text{sum over cores of active time}] / (\text{core\_count} \times \text{total elapsed time}) \times 100\%.$$0 moments and $$\text{CPU utilization} = [\text{sum over cores of active time}] / (\text{core\_count} \times \text{total elapsed time}) \times 100\%.$$1 random vectors (Wang et al., 8 Sep 2025).

The LSQT component uses the standard KPM rescaling and Chebyshev recursion. After rescaling $$\text{CPU utilization} = [\text{sum over cores of active time}] / (\text{core\_count} \times \text{total elapsed time}) \times 100\%.$$2 to $$\text{CPU utilization} = [\text{sum over cores of active time}] / (\text{core\_count} \times \text{total elapsed time}) \times 100\%.$$3 with spectrum in $$\text{CPU utilization} = [\text{sum over cores of active time}] / (\text{core\_count} \times \text{total elapsed time}) \times 100\%.$$4, the recursion is

$$\text{CPU utilization} = [\text{sum over cores of active time}] / (\text{core\_count} \times \text{total elapsed time}) \times 100\%.$$5

with stochastic moments

$$\text{CPU utilization} = [\text{sum over cores of active time}] / (\text{core\_count} \times \text{total elapsed time}) \times 100\%.$$6

The DOS approximation is

$$\text{CPU utilization} = [\text{sum over cores of active time}] / (\text{core\_count} \times \text{total elapsed time}) \times 100\%.$$7

Transport uses velocity autocorrelation and Kubo–Greenwood forms, while carrier concentration and mobility are obtained from

$$\text{CPU utilization} = [\text{sum over cores of active time}] / (\text{core\_count} \times \text{total elapsed time}) \times 100\%.$$8

The paper reports a velocity-autocorrelation time step of 0.1 fs and random-state propagation for more than 200 steps to achieve good convergence (Wang et al., 8 Sep 2025).

The practical envelope is unusually large for an ML-generated Hamiltonian workflow. The framework computed DOS for pristine graphene systems of more than 100 million atoms, approximately 1 billion orbitals with $$\text{CPU utilization} = [\text{sum over cores of active time}] / (\text{core\_count} \times \text{total elapsed time}) \times 100\%.$$9 and third-nearest-neighbor cutoff, on NVIDIA H100 80 GB, while training and other large-scale calculations used NVIDIA A100 SXM4 40 GB and H100 SXM5 80 GB. Applications include 3-million-atom and 2.4-million-atom SiGe systems at 300 K, a 6.5-million-atom graphene mobility calculation reproducing $$T_{\text{total}} = T_{\text{compute}} + T_{\text{comm}} + T_{\text{io}} + T_{\text{overhead}},$$0 over carrier concentrations of approximately $$T_{\text{total}} = T_{\text{compute}} + T_{\text{comm}} + T_{\text{io}} + T_{\text{overhead}},$$1–$$T_{\text{total}} = T_{\text{compute}} + T_{\text{comm}} + T_{\text{io}} + T_{\text{overhead}},$$2, and 1-million-atom h-BN/graphene heterojunction DOS calculations. The framework also supports spin–orbit coupling channels, although the paper notes that strongly correlated systems, complex metallic surfaces, and water–metal interfaces may require richer basis sets and more expressive models (Wang et al., 8 Sep 2025).

4. TBD-GPU as a block-tridiagonal GPU solver

In numerical linear algebra, TBD-GPU denotes an open-source, cross-platform GPU solver for symmetric positive definite block-tridiagonal systems

$$T_{\text{total}} = T_{\text{compute}} + T_{\text{comm}} + T_{\text{io}} + T_{\text{overhead}},$$3

where $$T_{\text{total}} = T_{\text{compute}} + T_{\text{comm}} + T_{\text{io}} + T_{\text{overhead}},$$4 has $$T_{\text{total}} = T_{\text{compute}} + T_{\text{comm}} + T_{\text{io}} + T_{\text{overhead}},$$5 diagonal blocks of size $$T_{\text{total}} = T_{\text{compute}} + T_{\text{comm}} + T_{\text{io}} + T_{\text{overhead}},$$6 and $$T_{\text{total}} = T_{\text{compute}} + T_{\text{comm}} + T_{\text{io}} + T_{\text{overhead}},$$7 coupling blocks between consecutive time steps. The solver targets NVIDIA and AMD backends through CUDA and ROCm, supports single and double precision, and is designed for time-dependent estimation and optimal control problems in which the block-tridiagonal structure is known a priori (Jin et al., 3 Sep 2025).

The mathematical basis is a recursive Schur-complement reduction that reorganizes sequential block elimination into a hierarchy of independent interior segments and separator systems. The sequential block-Cholesky sweep provides the local base operations:

$$T_{\text{total}} = T_{\text{compute}} + T_{\text{comm}} + T_{\text{io}} + T_{\text{overhead}},$$8

followed recursively by forward and backward substitution. The parallelization enabler is a symmetric permutation that partitions the system into interior and separator variables,

$$T_{\text{total}} = T_{\text{compute}} + T_{\text{comm}} + T_{\text{io}} + T_{\text{overhead}},$$9

then eliminates interiors through

$$T_{\text{comm}} \approx \text{bytes}_{\text{transferred}} / \text{bandwidth} + \text{latency} \times \text{message}_{\text{count}},$$0

Because $$T_{\text{comm}} \approx \text{bytes}_{\text{transferred}} / \text{bandwidth} + \text{latency} \times \text{message}_{\text{count}},$$1 is block-diagonal across disjoint interior segments, its factorizations and solves become fully parallel batched dense-kernel workloads (Jin et al., 3 Sep 2025).

The implementation maps this structure to batched BLAS/LAPACK kernels. Interior segment factorization uses batched POTRF on diagonal blocks, batched TRSM to form off-diagonal factors, and batched SYRK or GEMM to update the next diagonal block. The intermediate factor $$T_{\text{comm}} \approx \text{bytes}_{\text{transferred}} / \text{bandwidth} + \text{latency} \times \text{message}_{\text{count}},$$2, defined implicitly by solving $$T_{\text{comm}} \approx \text{bytes}_{\text{transferred}} / \text{bandwidth} + \text{latency} \times \text{message}_{\text{count}},$$3, is computed with batched forward and backward block-triangular solves. Schur complement formation then uses batched GEMM for $$T_{\text{comm}} \approx \text{bytes}_{\text{transferred}} / \text{bandwidth} + \text{latency} \times \text{message}_{\text{count}},$$4 and scatter-add assembly into $$T_{\text{comm}} \approx \text{bytes}_{\text{transferred}} / \text{bandwidth} + \text{latency} \times \text{message}_{\text{count}},$$5. The same structure is reused in the solve phase for separator right-hand-side updates, recursive solution of $$T_{\text{comm}} \approx \text{bytes}_{\text{transferred}} / \text{bandwidth} + \text{latency} \times \text{message}_{\text{count}},$$6, and recovery of interior unknowns via batched TRSM. The paper lists cuBLAS/cuSOLVER on NVIDIA and rocBLAS/rocSOLVER on AMD as the vendor libraries used, with SPD structure permitting pivot-free Cholesky (Jin et al., 3 Sep 2025).

The complexity remains $$T_{\text{comm}} \approx \text{bytes}_{\text{transferred}} / \text{bandwidth} + \text{latency} \times \text{message}_{\text{count}},$$7 for factorization and $$T_{\text{comm}} \approx \text{bytes}_{\text{transferred}} / \text{bandwidth} + \text{latency} \times \text{message}_{\text{count}},$$8 for solving with $$T_{\text{comm}} \approx \text{bytes}_{\text{transferred}} / \text{bandwidth} + \text{latency} \times \text{message}_{\text{count}},$$9 right-hand sides, matching sequential block-Cholesky asymptotically. The gain lies in reorganizing work into a small number of large batched kernels per recursion level. Matrices are stored contiguously in device memory, with device-side arrays of pointers passed to batched kernels; array-of-pointers is used for flexibility with heterogeneous segment lengths, and strided-batched variants are possible when dimensions are uniform. The paper emphasizes that all recursion levels are currently invoked sequentially, so inter-level overlap is limited even though each level exposes large intra-level parallelism (Jin et al., 3 Sep 2025).

Benchmarking was performed in FP64 on NVIDIA H200 with CUDA 12.4, AMD MI300X with ROCm 6.4.1, and CPU baselines on Intel Xeon Platinum 8562Y+ using MKL. Synthetic SPD block-tridiagonal matrices were generated with fixed total unknowns $$T_{\text{ring}} \approx 2 \times (N-1)/N \times (\text{bytes}/\text{bandwidth}) + 2 \times (N-1) \times \text{latency}.$$0 and block sizes $$T_{\text{ring}} \approx 2 \times (N-1)/N \times (\text{bytes}/\text{bandwidth}) + 2 \times (N-1) \times \text{latency}.$$1. Selected results show that for $$T_{\text{ring}} \approx 2 \times (N-1)/N \times (\text{bytes}/\text{bandwidth}) + 2 \times (N-1) \times \text{latency}.$$2, total time was 83.42 ms for TBD-GPU versus 180.16 ms for cuDSS, with factorization times of 61.72 ms and 173.87 ms. For $$T_{\text{ring}} \approx 2 \times (N-1)/N \times (\text{bytes}/\text{bandwidth}) + 2 \times (N-1) \times \text{latency}.$$3, total time was 162.09 ms versus 314.71 ms. For $$T_{\text{ring}} \approx 2 \times (N-1)/N \times (\text{bytes}/\text{bandwidth}) + 2 \times (N-1) \times \text{latency}.$$4, total time was 315.06 ms versus 346.59 ms. Against CPU solvers, the reported speedups are much larger: at $$T_{\text{ring}} \approx 2 \times (N-1)/N \times (\text{bytes}/\text{bandwidth}) + 2 \times (N-1) \times \text{latency}.$$5, TBD-GPU took 0.315 s versus CHOLMOD 59.864 s and MA57 104.949 s; at $$T_{\text{ring}} \approx 2 \times (N-1)/N \times (\text{bytes}/\text{bandwidth}) + 2 \times (N-1) \times \text{latency}.$$6, 0.162 s versus 25.971 s and 36.292 s. Residuals were consistently in the $$T_{\text{ring}} \approx 2 \times (N-1)/N \times (\text{bytes}/\text{bandwidth}) + 2 \times (N-1) \times \text{latency}.$$7–$$T_{\text{ring}} \approx 2 \times (N-1)/N \times (\text{bytes}/\text{bandwidth}) + 2 \times (N-1) \times \text{latency}.$$8 range in FP64 (Jin et al., 3 Sep 2025).

The same results also delimit the preferred operating regime. cuDSS is faster for small block sizes, with examples such as $$T_{\text{ring}} \approx 2 \times (N-1)/N \times (\text{bytes}/\text{bandwidth}) + 2 \times (N-1) \times \text{latency}.$$9, where total time was 19.49 ms for TBD-GPU versus 11.79 ms for cuDSS, and $$M_{\text{total}} = M_{\text{weights}} + M_{\text{activations}} + M_{\text{gradients}} + M_{\text{workspace}} \; (+ M_{\text{dynamic}} \text{ where applicable}).$$0, where total time was 12.32 ms versus 5.01 ms. The paper therefore recommends the method when the known block-tridiagonal SPD structure is present and blocks are moderately large, specifically noting that in FP64 on H200 and MI300X the method begins to overtake cuDSS around $$M_{\text{total}} = M_{\text{weights}} + M_{\text{activations}} + M_{\text{gradients}} + M_{\text{workspace}} \; (+ M_{\text{dynamic}} \text{ where applicable}).$$1. Its reported application contexts include Kalman smoothing and condensed SPD forms arising in optimal control and MPC (Jin et al., 3 Sep 2025).

5. TBD-GPU as predictable GPU access in real-time systems

In real-time systems, TBD-GPU denotes a server-based approach for predictable and efficient GPU access under partitioned fixed-priority preemptive CPU scheduling. The motivating problem is that many commercial GPUs execute requests sequentially and non-preemptively, COTS drivers are generally priority-unaware, and synchronization-based analyses such as MPCP and FMLP+ typically model GPU segments as non-suspending critical sections. In the GPU setting this induces busy-waiting during kernel execution and DMA, wastes CPU cycles, and can create long priority inversion through priority boosting (Kim et al., 2017).

The proposed architecture introduces a dedicated GPU server task at the highest system priority. Client tasks issue GPU requests to the server, then self-suspend; the server maintains a priority queue ordered by client task priority, dispatches requests one at a time, performs CPU-side miscellaneous operations, and suspends during GPU-execution intervals. The assumed task model is

$$M_{\text{total}} = M_{\text{weights}} + M_{\text{activations}} + M_{\text{gradients}} + M_{\text{workspace}} \; (+ M_{\text{dynamic}} \text{ where applicable}).$$2

where $$M_{\text{total}} = M_{\text{weights}} + M_{\text{activations}} + M_{\text{gradients}} + M_{\text{workspace}} \; (+ M_{\text{dynamic}} \text{ where applicable}).$$3 is normal CPU execution time, $$M_{\text{total}} = M_{\text{weights}} + M_{\text{activations}} + M_{\text{gradients}} + M_{\text{workspace}} \; (+ M_{\text{dynamic}} \text{ where applicable}).$$4 the minimum inter-arrival time, $$M_{\text{total}} = M_{\text{weights}} + M_{\text{activations}} + M_{\text{gradients}} + M_{\text{workspace}} \; (+ M_{\text{dynamic}} \text{ where applicable}).$$5 the relative deadline, $$M_{\text{total}} = M_{\text{weights}} + M_{\text{activations}} + M_{\text{gradients}} + M_{\text{workspace}} \; (+ M_{\text{dynamic}} \text{ where applicable}).$$6 the maximum accumulated uncontended GPU-segment duration, and $$M_{\text{total}} = M_{\text{weights}} + M_{\text{activations}} + M_{\text{gradients}} + M_{\text{workspace}} \; (+ M_{\text{dynamic}} \text{ where applicable}).$$7 the number of GPU access segments per job. Each GPU segment is decomposed as

$$M_{\text{total}} = M_{\text{weights}} + M_{\text{activations}} + M_{\text{gradients}} + M_{\text{workspace}} \; (+ M_{\text{dynamic}} \text{ where applicable}).$$8

with $$M_{\text{total}} = M_{\text{weights}} + M_{\text{activations}} + M_{\text{gradients}} + M_{\text{workspace}} \; (+ M_{\text{dynamic}} \text{ where applicable}).$$9 the WCET of pure GPU operations requiring no CPU and $$H = \sum_i \epsilon_i c_i^{\dagger} c_i + \sum_{i\neq j} t_{ij} c_i^{\dagger} c_j + h.c.,$$0 the WCET of CPU-side miscellaneous operations, including the cost of triggering self-suspension (Kim et al., 2017).

The analysis introduces a per-request server overhead $$H = \sum_i \epsilon_i c_i^{\dagger} c_i + \sum_{i\neq j} t_{ij} c_i^{\dagger} c_j + h.c.,$$1, upper-bounding server wake-up, priority-queue operations, and completion notification. The maximum total GPU-server handling time for one job is

$$H = \sum_i \epsilon_i c_i^{\dagger} c_i + \sum_{i\neq j} t_{ij} c_i^{\dagger} c_j + h.c.,$$2

where $$H = \sum_i \epsilon_i c_i^{\dagger} c_i + \sum_{i\neq j} t_{ij} c_i^{\dagger} c_j + h.c.,$$3 is an upper bound on total waiting time across the job’s GPU segments. To reduce pessimism, the waiting-time bound is double-bounded as

$$H = \sum_i \epsilon_i c_i^{\dagger} c_i + \sum_{i\neq j} t_{ij} c_i^{\dagger} c_j + h.c.,$$4

where $$H = \sum_i \epsilon_i c_i^{\dagger} c_i + \sum_{i\neq j} t_{ij} c_i^{\dagger} c_j + h.c.,$$5 is request-driven and $$H = \sum_i \epsilon_i c_i^{\dagger} c_i + \sum_{i\neq j} t_{ij} c_i^{\dagger} c_j + h.c.,$$6 is job-driven. The request-driven recurrence for the $$H = \sum_i \epsilon_i c_i^{\dagger} c_i + \sum_{i\neq j} t_{ij} c_i^{\dagger} c_j + h.c.,$$7-th GPU segment is

$$H = \sum_i \epsilon_i c_i^{\dagger} c_i + \sum_{i\neq j} t_{ij} c_i^{\dagger} c_j + h.c.,$$8

and the job-driven bound is

$$H = \sum_i \epsilon_i c_i^{\dagger} c_i + \sum_{i\neq j} t_{ij} c_i^{\dagger} c_j + h.c.,$$9

These equations formalize bounded waiting under non-preemptive GPU service with priority-ordered queueing (Kim et al., 2017).

Response-time analysis is then expressed in self-suspending-task form. When the server is on a different core,

$$\epsilon_i = f_\epsilon(\mathbf{D}_i; \theta), \qquad t_{ij} = f_t(\mathbf{D}_{ij}; \phi).$$0

When the server shares the same core with $$\epsilon_i = f_\epsilon(\mathbf{D}_i; \theta), \qquad t_{ij} = f_t(\mathbf{D}_{ij}; \phi).$$1, an additional interference term accounts for the server’s CPU-side miscellaneous work:

$$\epsilon_i = f_\epsilon(\mathbf{D}_i; \theta), \qquad t_{ij} = f_t(\mathbf{D}_{ij}; \phi).$$2

The server can also be assigned a utilization for bin packing,

$$\epsilon_i = f_\epsilon(\mathbf{D}_i; \theta), \qquad t_{ij} = f_t(\mathbf{D}_{ij}; \phi).$$3

This analytical framework is explicitly presented as an improvement over an earlier request-driven-only bound through the combined Server-RD+JD method (Kim et al., 2017).

The prototype was implemented on a SABRE Lite board with an NXP i.MX6 Quad SoC, four ARM Cortex-A9 cores at 1 GHz, a Vivante GC2000 GPU, Linux/RK kernel 3.14.52, Vivante v5.0.11p7.4 driver, and OpenCL 1.1 Embedded Profile. The synchronization baseline used Linux/RK kernel-level MPCP, with busy-waiting on OpenCL events, whereas the server-based implementation used shared memory per client, POSIX signals, asynchronous memory copy and kernel execution, and suspension via clFinish(). Measured worst-case overheads at the 99.9th percentile over 100,000 runs were 14.0 µs for the synchronization-based lock overhead and 44.97 µs for server overhead; schedulability experiments used $$\epsilon_i = f_\epsilon(\mathbf{D}_i; \theta), \qquad t_{ij} = f_t(\mathbf{D}_{ij}; \phi).$$4 µs (Kim et al., 2017).

The empirical results emphasize schedulability rather than throughput. In a case study over one hyperperiod of 3,000 ms, cpu_matmul1 had worst-case response time 520.68 ms under synchronization and 219.09 ms under the server-based approach. In random task-set experiments, the server-based method outperformed MPCP and FMLP+ across most practical settings. One highlighted result reports up to 38% more schedulable task sets than MPCP and 27% more than FMLP+ when 70% of tasks use the GPU and $$\epsilon_i = f_\epsilon(\mathbf{D}_i; \theta), \qquad t_{ij} = f_t(\mathbf{D}_{ij}; \phi).$$5. The paper also reports sensitivity to the overhead $$\epsilon_i = f_\epsilon(\mathbf{D}_i; \theta), \qquad t_{ij} = f_t(\mathbf{D}_{ij}; \phi).$$6, the ratio $$\epsilon_i = f_\epsilon(\mathbf{D}_i; \theta), \qquad t_{ij} = f_t(\mathbf{D}_{ij}; \phi).$$7, and the minimum task period $$\epsilon_i = f_\epsilon(\mathbf{D}_i; \theta), \qquad t_{ij} = f_t(\mathbf{D}_{ij}; \phi).$$8, with the server-based approach losing ground only under unusually large miscellaneous CPU fractions or unfavorable period structures (Kim et al., 2017).

6. Comparative perspective and recurring GPU design motifs

Across these distinct usages, several recurring technical patterns are visible. First, each usage exploits a strong prior structure: DNN operator structure and training phases in TBD benchmarking, orthogonal sparse tight-binding Hamiltonians and LSQT recursions in GPUTB, block-tridiagonal SPD sparsity in the solver, and sequential non-preemptive GPU service in real-time management. This suggests that “TBD-GPU” is less a unified software family than a recurring design stance: expose the structure that governs GPU bottlenecks, then reorganize work or analysis around that structure (Zhu et al., 2018, Wang et al., 8 Sep 2025, Jin et al., 3 Sep 2025, Kim et al., 2017).

Second, the meaning of GPU efficiency differs sharply across subfields. In DNN training, efficiency is characterized by compute utilization, FP32 utilization, workspace tradeoffs, and communication overlap. In ML tight-binding, the critical quantities are orthogonal Hamiltonian construction, sparse SpMV efficiency, KPM or VAC propagation length, and linear scaling to millions or more than 100 million atoms. In block-tridiagonal solution, efficiency depends on the ability to batch dense kernels so that kernel-launch overhead is amortized and arithmetic intensity is high. In real-time scheduling, the relevant metric is schedulability under bounded waiting, not raw FLOP throughput. A plausible implication is that claims about “GPU performance” under one TBD-GPU usage cannot be transferred directly to another without changing the objective function.

Third, all of the works identify a limiting factor outside nominal peak compute. The DNN benchmark highlights low-utilization kernels such as batch normalization, activation-dominated memory footprints, and interconnect sensitivity in distributed training. GPUTB highlights the historical bottleneck of transferability and orthogonalization in tight-binding workflows, and removes diagonalization from the large-scale path by using LSQT. The block-tridiagonal solver highlights recursion-level serialization and small-block launch overhead. The server-based real-time work highlights priority inversion, busy-waiting, and server overhead $$\epsilon_i = f_\epsilon(\mathbf{D}_i; \theta), \qquad t_{ij} = f_t(\mathbf{D}_{ij}; \phi).$$9. The shared lesson is that GPU-centered system design is governed by orchestration, memory movement, and execution granularity as much as by peak arithmetic capability (Zhu et al., 2018, Wang et al., 8 Sep 2025, Jin et al., 3 Sep 2025, Kim et al., 2017).

A common misconception would be to treat TBD-GPU as a single package, benchmark suite, or algorithmic lineage. The cited literature does not support that interpretation. Another misconception would be to treat the 2018 TBD benchmark as identical to later “TBD-GPU” systems; the benchmark is a related but distinct GPU-focused training-evaluation framework. Conversely, the later works are application-specific systems in electronic-structure computation, sparse structured solvers, and predictable accelerator management. The term is therefore best understood as polysemous, with each usage anchored in a specific research community and technical problem formulation (Zhu et al., 2018, Wang et al., 8 Sep 2025, Jin et al., 3 Sep 2025, Kim et al., 2017).