Feasibility of Implementing Motion-Compensated Magnetic Resonance Imaging Reconstruction on Graphics Processing Units Using Compute Unified Device Architecture

Abstract

Motion correction in magnetic resonance imaging (MRI) has become increasingly complex due to the high computational demands of iterative reconstruction algorithms and the heterogeneity of emerging computing platforms. However, the clinical applicability of these methods requires fast processing to ensure rapid and accurate diagnostics. Graphics processing units (GPUs) have demonstrated substantial performance gains in various reconstruction tasks. In this work, we present a GPU implementation of the reconstruction kernel for the generalized reconstruction by inversion of coupled systems (GRICS), an iterative joint optimization approach that enables 3D high-resolution image reconstruction with motion correction. Three implementations were compared: (i) a C++ CPU version, (ii) a Matlab–GPU version (with minimal code modifications allowing data storage in GPU memory), and (iii) a native GPU version using CUDA. Six distinct datasets, including various motion types, were tested. The results showed that the Matlab–GPU approach achieved speedups ranging from 1.2× to 2.0× compared to the CPU implementation, whereas the native CUDA version attained speedups of 9.7× to 13.9×. Across all datasets, the normalized root mean square error (NRMSE) remained on the order of ${10}^{-6}$ to ${10}^{-4}$, indicating that the CUDA-accelerated method preserved image quality. Furthermore, a roofline analysis was conducted to quantify the kernel’s performance on one of the evaluated datasets. The kernel achieved 250 GFLOP/s, representing a 15.6× improvement over the performance of the Matlab–GPU version. These results confirm that GPU-based implementations of GRICS can drastically reduce reconstruction times while maintaining diagnostic fidelity, paving the way for more efficient clinical motion-compensated MRI workflows.

1. Introduction

The recent advances in magnetic resonance imaging (MRI) programs have led to multiple implementation challenges. The computational demands of MRI scales with advancements in imaging techniques, especially with the transition to real-time imaging [1] and model-based reconstructions [2]. Modern MRI systems face challenges including the need for higher spatial and temporal resolution, the reduction in acquisition time, and the integration of advanced techniques such as dynamic imaging [3], compressed sensing [4], and parallel imaging [5]. For instance, the motion-compensated MRI reconstruction problem relies on accurate modeling of rigid and non-rigid body motion, which implies an exact modeling of the deformation and a local tracking of the displacement fields within each voxel [6]. Hence, thousands of variables are required. Thus, it is necessary to assess the data-level parallelism in MRI reconstruction methods and employ high-performance computing (HPC) platforms to reduce the reconstruction time to an acceptable level for clinical applicability. Graphics processing units (GPUs) are suited for iterative, high-throughput operations, critical to MRI workflows, such as Fourier transforms, image interpolation, and gridding [7,8,9]. Unlike traditional central processing units (CPUs), GPUs are designed for data-level parallelism, enabling the processing of thousands of threads concurrently. Moreover, GPUs facilitate memory-intensive processes such as multi-frame parallel reconstruction, leveraging their superior memory bandwidth and multi-core architecture [10]. In parallel with fast GPU-driven reconstruction, a new trend is emerging toward multi-sensory pipelines that fuse imaging with real-time safety monitoring. Smart electronic-device platforms now enable continuous streaming of tissue temperature and local specific absorption rate (SAR) data, which can be co-processed on the same GPU hardware to guide adaptive control of power deposition and reconstruction parameters [11]. Integrating such wearable sensor feedback underscores the broader move toward unified, GPU-centric biomedical systems where imaging, physiology, and patient safety are handled in a single low-latency loop. Compute unified device architecture (CUDA) [12] has gained particular attention in MRI GPU-transition for its user-friendly programming model, its accessibility, and its high-level libraries. In this work, we extend our research reported in [13] by introducing the CUDA implementation of the generalized reconstruction by inversion of coupled systems (GRICS) method’s reconstruction kernel [14], an iterative reconstruction framework that allows for the obtention of 3D high-resolution images, by alternatively optimizing the reconstructed image and the parameters of the motion model. A key contribution of our study lies in the design of the CUDA implementation of the reconstruction kernel, particularly, the optimal design of sparse matrix–vector/element-wise matrix multiplication to efficiently use warp-level parallelism, and the on-the-fly computation of the motion operator. Rather than repeatedly transferring precomputed elements from the CPU to the GPU, the required non-zero entries of the operator are dynamically generated within the target kernels based on the underlying motion model. Despite a higher per-iteration computational cost, this design significantly reduces data-transfer overhead and memory usage, while ensuring that all problem variables remain in GPU memory throughout the iterative process. Moreover, advanced parallel-reduction strategies using atomic operations further guarantee safe and optimal accumulation of partial results in the shared memory. Furthermore, a performance analysis is used to compare the efficiency of three implementations: the CPU-C++, the Matlab-GPU [13], and the CUDA implementations. We evaluated the eventual discrepancies between the CPU and CUDA images with the normalized root mean square error (NRMSE). A second contribution is the roofline analysis of the reconstruction kernel applied to a specific dataset. The roofline model [14] was used to quantify the performance of the operators involved in the reconstruction step. This analysis provides a performance baseline for iterative reconstruction programs since they share the same performance bottlenecks as GRICS [6].

2. Theory

2.1. Joint Reconstruction of an Image and a Motion Model

Motion-compensated reconstruction was accomplished using the GRICS method [6,14]. The algorithm solves alternatively and iteratively for both a motion-corrected image $\rho$ and the parameters of a motion model $\alpha$. The software corrects for either rigid or non-rigid body motion. The problem is formulated as follows:

$$\left\{\begin{array}{c}\rho ,\alpha =\underset{\rho ,\alpha }{arg\; min}\left|\right|E\left(u_{\alpha }\right)\rho -{m\left|\right|}^2+{\lambda \left|\right|\rho \left|\right|}^2+\mu R\left(\alpha \right),\hfill \\ u_{\alpha }(x,y,z,t)=\left\{\begin{array}{c}[x,y,z,1]\alpha \left(t\right)(\mathrm{rigid}\mathrm{model}),\mathrm{or}\hfill \\ \alpha (x,y,z)s\left(t\right)(\mathrm{non-rigid}\mathrm{model})\hfill \end{array}\right.\hfill \end{array}\right.$$

(1)

where m stands for the acquired MRI k-space data, $u_{\alpha }$ is the displacement field at each k-space sample time, and E is the encoding operator (a complete description of the encoding operator E can be found in [13]). In the case of a rigid motion model, $\alpha \left(t\right)$ represents a rigid transformation matrix; it is expressed using homogeneous coordinates. In the case of a non-rigid motion model, a separable motion model is used, with a spatial component $\alpha (x,y,z)$, and the temporal component $s\left(t\right)$ is a motion signal, acquired from a motion sensor or navigator data. A Tikhonov regularization controlled by the hyper-parameter $\lambda$ is employed. An additional regularization term is added in the non-rigid case, as $R\left(\alpha \right)={\left|\right|\nabla \alpha \left|\right|}^2$. In each iteration of the GRICS algorithm, two coupled least-squares problems are solved in an alternating scheme. The first problem addresses image reconstruction, where the objective is to recover the image $\rho$ by minimizing the discrepancy between the measured k-space data and the forward model, as well as the regularization term that stabilizes the solution. Once the image is updated, the motion correction problem is tackled in the second least-squares step. Here, the residual from the reconstructed image is used to refine the motion parameters $\alpha$ (either under rigid or non-rigid motion assumptions). By linearizing the forward model around the current estimates, a Gauss–Newton method efficiently updates $\alpha$ to reduce motion-induced artifacts. The least-squares problems are solved using the Conjugate Gradient (CG) solver. This iterative interplay between image reconstruction and motion estimation is applied in a multi-resolution fashion: first, it is applied to the low-resolution (central) k-space data; then, it continues until the last resolution level, where only the reconstruction step is performed.

2.2. The Roofline Model

To characterize the performance of our GPU implementation, we employ the roofline model [15], which is a visual framework for understanding how kernel performance is limited by both the available memory bandwidth and the peak computational throughput. A key component of this model is the operational/arithmetic intensity, defined as

$$\mathrm{OI}={\displaystyle \frac{\mathrm{FLOPs}}{\mathrm{Bytes}\mathrm{transferred}}},$$

where FLOPs is the total number of FLoating-point Operations performed and bytes transferred is the total amount of data read or written from memory. The roofline model states that the maximum achievable performance P cannot exceed either the GPU’s peak floating-point performance $P_{\mathrm{peak}}$ or the product of the operational intensity and the peak memory bandwidth $B_{\mathrm{peak}}$:

$$P\le min(P_{\mathrm{peak}},OI\times B_{\mathrm{peak}})$$

(2)

This formulation highlights whether a given kernel is compute-bound (limited by $P_{\mathrm{peak}}$) or memory-bound (limited by $B_{\mathrm{peak}}$). By plotting the measured performance against OI on the same axes as these theoretical “roofs”, it is possible to identify performance bottlenecks and optimization patterns; see Figure 1.

3. Methods

3.1. Data Acquisition

In this study, we investigated data acquired through two separate MRI examinations conducted on different imaging systems. For the first acquisition, raw MRI data were obtained using a 3T MRI scanner (MAGNETOM Prisma, Siemens Healthineers, Erlangen, Germany). Three volunteers were enrolled, and three datasets $(D_1,D_2,D_3)$ with non-rigid motion were acquired using a T1-weighted 3D fast low-angle shot GRadient Echo (GRE) sequence covering the breast region in a 90 s free-breathing scan. Additional details regarding this acquisition and its ethical approval are available in [13,16]. For the second acquisition, MRI data were acquired using a 7T MRI scanner (Magnetom 7T, Siemens Healthineers) equipped with an in-house built head RF coil having 8 transmit and 32 receive channels [17]. Here, 3 datasets $(D_4,D_5,D_6)$ containing subtle rigid motion from 3 volunteers were obtained with a 3D Magnetization Prepared Rapid Gradient Echo (MPRAGE) [18] sequence covering the head at a resolution of $1\times 1\times 1$ ${\mathrm{mm}}^3$. To enhance motion sensitivity, the MPRAGE sequence was modified to randomize the k-space sampling order. This randomization evenly distributes motion-induced artifacts, effectively transforming them into less noticeable, noise-like distortions and making them more suitable to advanced reconstruction techniques [19]. Additionally, it improves temporal resolution by enabling more flexible sampling strategies that adapt to motion dynamics and capture more relevant temporal information. A navigator (the central k-space line, a line scan oriented along the inferior-to-superior IS direction) was acquired at the beginning of each RAGE shot and was processed in order to split the k-space data into $N_t$ motion states. All participants in these studies provided written informed consent. Volunteers were not instructed to move. A summary of the dataset parameters is depicted in

Table 1. $N_x,N_y,N_z$ are the number of samples in frequency encoding, phase-encoding, and slices directions, respectively. $N_c$ is the number of coils in the coil array. $N_t$ is the number of motion states.

Dataset	${\mathit{D}}_1$	${\mathit{D}}_2$	${\mathit{D}}_3$	${\mathit{D}}_4$	${\mathit{D}}_5$	${\mathit{D}}_6$
$N_x$	320	320	320	256	256	256
$N_y$	470	470	550	208	208	208
$N_z$	112	112	112	160	160	160
$N_c$	20	30	26	32	32	32
$N_t$	12	12	12	12	12	12
Magnetic Field	3T	3T	3T	7T	7T	7T

.

3.2. The Reconstruction Kernel

The most computationally-intensive part of GRICS lies in the Conjugate Gradient (CG) linear solvers. In particular, the application of the operator $E^{H}E$—where $E^H$ is the Hermitian transpose of the operator E—comprises an outer loop on motion states $N_t$ and an inner loop on coil receivers $N_c$. Algorithm 1 introduces the structure of this kernel. The operator $E^{H}E$ reads

$$E^{H}E=\sum _{\begin{array}{c}t=1\end{array}}^{N_t}{T}_t^H\left(\sum _{\begin{array}{c}c=1\end{array}}^{N_c}{C}_c^H{F}^H{S}_t^H{S}_{t}F{C}_c\right)T_t$$

(3)

A complete description of the operators in Equation (3) and of the C++ and Matlab–GPU implementations of Algorithm 1 can be found in [13].

Algorithm 1 Main part of the reconstruction kernel (function $x\mapsto E^{H}Ex$).

1: $y=0$ 2: for $t=1,2,\dots ,N_t$ do 3:      $x_t=T\left(u_t\right)x$ 4:      $y_t=0$ 5:      for coil $c=1,2,\dots ,N_c$ do 6:          $y_t=y_t+C_c^H\left(F^H{S}_t^H{S}_{t}F\right)C_c{x}_t$ 7:      end for 8:      $y=y+T{\left(u_t\right)}^H{y}_t$ 9: end for

3.3. Cuda Implementation

In order to implement Algorithm 1 in a GPU with CUDA, several kernels and mathematical operations were designed. First, the application of the Sensitivity Maps operator $C_c$ and its Hermitian transpose $C_c^H$ required the implementation of an element-wise complex multiplication, where each thread processes one data point, performing concurrently the real and imaginary parts of the complex multiplication for all the elements. Another element-wise product kernel was designed to apply the sampling mask operator $S_t^H{S}_t$. The kernels for the displacement operator $T_t$ and its Hermitian transpose $T_t^H$ assign threads to individual voxels and compute displacement fields based on rigid or non-rigid motion parameters, warping the image using linear interpolation. In the C++ implementation, the non-zero elements of $T_t$ were precomputed before the CG solver was run and stored in CPU memory. In the Matlab–GPU implementation, due to the GPU memory limitation, the precomputed elements had to be transferred from the CPU to the GPU memory at the beginning of the outer loop (before line 3 of Algorithm 1). To avoid this repeated and costly transfer, in the native CUDA implementation, the non-zero elements of $T_t$ were computed dynamically within the kernel from the motion model definition given in Equation 1. This resulted in a higher computational complexity; however, all the required problem variables were stored in GPU memory before running the CG solver. The Fast Fourier Transform FFT algorithm was implemented using the GPU-optimized library cuFFT [20]. Moreover, and in order to avoid race conditions, atomicAdd was explicitly employed at multiple locations, mainly in the reduction process (line 8 in Algorithm 1), to safely accumulate partial results into the shared memory location. Finally, the CG solver was implemented using the cuBLAS library [21].

3.4. The Test Machines

The CPU-only implementation of Algorithm 1 was tested on an AMD EPYC 75F3 processor (AMD, Santa Clara, CA, USA). The C++ code benefits from a hybrid parallelization using Message Passing Interface (MPI) to distribute the $N_t$ motion states over n MPI ranks and Open Multi-Processing (OpenMP) to distribute the set of the $N_c$ coils over m software threads. The GPU implementations were executed on NVIDIA A100 GPU (NVIDIA Corporation, Santa Clara, CA, USA). More details about the two devices can be found in

Table 2. The main characteristics of the test machines. SM stands for streaming multi-processor, which is akin to cores in CPUs. FP stands for floating point. The bandwidth of the memory levels and the peak FP performance were estimated empirically with the Empirical Roofline Toolkit ERT [22]; it provides more realistic benchmarking of a workstation specs.

Device	AMD EPYC	NVIDIA A100
Main Memory bandwidth (GB/s)	221.1	1227.7
L2 Bandwidth (GB/s)	3242.2	3738.7
Main Memory Size (GB)	4000	40
Main Memory Type	DDR4	HBM2e
Nb Cores/SMs	36	108
Peak FP32 (GFLOP/s)	1348	12,526.1
Release year	2021	2020

.

3.5. Performance Profiling

In order to evaluate the performance of our CUDA-based implementation, we employed the NVIDIA Nsight Compute profiling tool [23]. Nsight Compute is a performance analysis utility specifically designed for NVIDIA GPUs, providing kernel-level profiling with a minimal overhead, with the aim of identifying and optimizing performance bottlenecks. In this context, Nsight Compute was used to collect performance metrics such as the FLOPs and memory traffic for both the main memory and the cache hierarchy. The set of the collected metrics is presented in

Table 3. NVIDIA Nsight Compute metrics. FP stands for floating point.

Data	Metric
FP 64	sm__sass_thread_inst_executed_op_fp64_pred_on.sum
FP 32	sm__sass_thread_inst_executed_op_fp32_pred_on.sum
FP 16	sm__sass_thread_inst_executed_op_fp16_pred_on.sum
Tensor Core	sm__inst_executed_pipe_tensor.sum
L1 cache	l1tex__t_bytes.sum
L2 cache	lts__t_bytes.sum
HBM	dram__bytes.sum

.

The operational intensities of each memory level are computed using the output of these metrics, in particular:

$$O{I}_{L_1}={\displaystyle \frac{\mathrm{FLOPs}}{L_1\mathrm{cache}}},O{I}_{L_2}={\displaystyle \frac{\mathrm{FLOPs}}{L_2\mathrm{cache}}},O{I}_{m_{HBM}}={\displaystyle \frac{\mathrm{FLOPs}}{\mathrm{HBM}}}.$$

Given that T is the elapsed time of the CUDA-based implementation, its achievable performance P is computed as

$$P={\displaystyle \frac{\mathrm{FLOPs}}{T}}$$

4. Results

To compare the performance of the three implementations, we measured the elapsed time per conjugate gradient (CG) iteration across the six datasets listed in Table 1. Each reported time represents the average of five runs. The results are shown in Figure 2, where the primary y-axis (left) indicates the elapsed time (in seconds) per CG iteration, and the secondary y-axis (right) denotes the speedup relative to the CPU reference implementation. The CUDA-based implementation significantly reduced the elapsed time, achieving speedup factors of between 9.7 and 13.9 (green dashed line) compared to the CPU-only version. The Matlab–GPU implementation (blue dashed line) also improved speedup but was less pronounced than the CUDA solution. The NRMSE of the CPU and the CUDA images are depicted in

Table 4. NRMSE of the CPU image and the CUDA image.

Dataset	NRMSE (CPU_Image, CUDA_Image)
$D_1$	${10}^{-5}$
$D_2$	${10}^{-6}$
$D_3$	${10}^{-5}$
$D_4$	${10}^{-4}$
$D_5$	${10}^{-4}$
$D_6$	${10}^{-4}$

. They remained within the range of ${10}^{-6}$ to ${10}^{-4}$ for all datasets. Since these values are lower than the reconstruction kernel’s tolerance of ${ϵ}_r={10}^{-3}$, no detectable image quality degradation was observed. Figure 3 presents a roofline analysis of the $E^{H}E$ operator, highlighting both the achievable performance and operational intensity for each operator in Algorithm 1. We relied on the Empirical Roofline Toolkit to measure realistic bandwidth and peak FP32/FP64 performance values rather than theoretical specifications. By computing the motion operator elements on the fly, the performance of operator $T_t$ was significantly enhanced, reaching 105 GFLOP/s. The Fast Fourier Transform (FFT) steps, executed via the cuFFT library, achieved 310 GFLOP/s. Overall, the $E^{H}E$ function is bandwidth-bound, exhibiting a performance of approximately 250 GFLOP/s at a high-bandwidth memory (HBM) operational intensity of 2.94 FLOP/Byte. For comparison, ref. [13] reported a performance of 16 GFLOP/s for the Matlab GPU implementation of Algorithm 1. In contrast, our native GPU implementation delivered a 15.6× performance gain, narrowing the gap to the roofline limits that define the upper bounds of achievable performance. Figure 4 and Figure 5 illustrate the reconstructed images for each implementation. In both the brain MRI dataset ($D_4$), subject to rigid-body motion, and the breast MRI dataset ($D_2$), subject to non-rigid respiratory and cardiac motion, the three methods effectively suppressed motion-induced artifacts.

5. Discussion

Compared to the CPU-only implementation, the GPU-based solutions significantly decreased computation time and improved the performance of Algorithm 1. In particular, the CUDA solution was approximately 9–13 times faster than the hybrid MPI/OpenMP version, exploiting the GPU micro-architecture without compromising the quality of the reconstructed images. For all datasets, the normalized root-mean-square error remained within the specified tolerance of the reconstruction kernel. For many years, one of the primary bottlenecks in GPU-based computing was the limited amount of device memory, which often forced data to be shuttled back and forth between the host and the device to fit larger workloads. This frequent transfer not only added latency but also introduced complexity in managing data pipelines for HPC applications. Recently, however, a new generation of GPUs (such as A100 GPU) has emerged with significantly expanded memory capacities, enabling developers to hold entire datasets directly in GPU memory. By offering more robust storage space and reducing reliance on host-to-device transfers, these GPUs improve the overall performance of such applications [25,26].

The roofline analysis showed substantial performance improvements with the CUDA implementation. However, the actual performance remains noticeably below the theoretical upper bound for the corresponding operational intensity. Potential future optimizations include the following:

• Data storage in half precision: Reducing the memory footprint by using FP16 could significantly enhance memory bandwidth utilization. An initial test was conducted with this constraint, and the reconstructed image quality was not compromised.
• Improvement of cache usage: Achieved by optimizing memory access patterns to benefit from the large L2 cache on the A100 GPU.
• The Utilization of tensor cores could be also investigated to accelerate matrix-based kernels.

The CUDA back-end is markedly cheaper to run. In our code, the A100 GPU performed each reconstruction in 5.3–18 s, whereas the 36-core EPYC 75F3 needed 53–180 s—a roughly 10-fold speedup. Even though a data-center A100 draws more instantaneous power than a single-socket EPYC (400 W versus 280 W, per vendor TDPs), the order-of-magnitude shorter runtime means the energy per study falls by approximately 80%. In a department that performs 2000 such motion-compensated scans a year, that difference translates to roughly 1 MWh saved—enough to pay the GPU’s electricity bill for the entire 5-year depreciation window.

6. Conclusions

In this work, we demonstrated the feasibility of a native GPU implementation of the GRICS method. By evaluating the CUDA-based implementation of the reconstruction kernel, which accounts for 70% to 80% of the total GRICS elapsed time, we achieved a speedup ranging from 9.7× to 13.7× with an elapsed time ranging between 5.3 s and 18 s across six different datasets, having different problem sizes and MRI acquisition types. The GPU acceleration did not compromise the reconstruction quality. The roofline analysis highlights an improvement in the overall performance with the CUDA implementation, with an achievable performance of 250 GFLOP/s. The results show the potential applicability of the method in clinical settings.