Industrial computed tomography (CT) reconstruction has traditionally relied on dedicated HPC infrastructure. Large datasets often require access to cluster nodes equipped with datacenter GPUs and substantial memory capacity, making deployment and operation expensive.
Recent advances in both hardware and software are changing this picture. Modern APUs combine increasingly capable integrated GPUs with large pools of unified memory, while reconstruction frameworks such as HTTomo have matured to the point where memory-bound algorithms can efficiently utilize these architectures.
In this article, we demonstrate that optimized Filtered BackProjection (FBP) and Log-Polar Reconstruction (LPRec) pipelines can run on a compact mini PC equipped with an AMD Ryzen AI Max+ PRO 395 APU, 128 GiB of unified memory, and a 2 TB NVMe SSD. For many reconstruction workloads, such a system can serve as a practical alternative to a dedicated cluster node while consuming significantly less space, power, and cost.
In our previous post, we demonstrated that the HTTomo reconstruction stack can run efficiently on a consumer AMD GPU. Here, we take the next step by evaluating reconstruction performance on a large-memory desktop APU and comparing it against datacenter accelerators on both benchmark-sized and large-scale datasets.
The results show that memory-intensive reconstruction algorithms can achieve performance comparable to a Tesla V100 while running on a compact desktop platform. More importantly, datasets that have traditionally required access to HPC resources can now be reconstructed on a locally deployed workstation-class system with a large unified memory pool.
Target platform
The primary system evaluated in this study is a Bosgame M5 AI Mini Desktop equipped with an AMD Ryzen AI Max+ PRO 395 APU. The system configuration is:
- 16 Zen 5 CPU cores
- 40 AMD RDNA™ 3.5 CUs
- 128GB of unified memory
- 2 TB NVMe SSD
The focus of this study is not the processor itself, but rather the capabilities enabled by the combination of integrated GPU compute and a large unified memory pool within a compact desktop system.
Small-dataset benchmark with HTTomo
To establish a baseline, we repeated the benchmark presented in our previous post on the desktop APU. The reconstruction pipeline and benchmark methodology are unchanged and are therefore not repeated here.
As before, these measurements are intended to provide performance context rather than support rigorous architectural comparisons. Differences in software stacks, memory architectures, and optimization levels make direct accelerator-to-accelerator comparisons difficult.
Each configuration was executed three times, and the best result from each set of runs is reported in Table 1:
| FBP [s] | LPRec [s] | FISTA [s] | |
| Radeon RX 7900 GRE | 42.496 | 41.064 | 474.027 |
| GeForce RTX 3060 Ti | 57.65 | 65.17 | 779.135 |
| Tesla V100 | 73.187 | 69.848 | 519.951 |
| NVIDIA L40S | 67.556 | 67.463 | 280.512 |
| AMD Ryzen™ AI MAX+ 395 | 74.725 | 70.333 | 1130.634 |
The results show that the desktop APU performs similarly to the Tesla V100 for the FBP and LPRec pipelines without any architecture-specific optimizations. The largest performance gap appears in FISTA, which is substantially more compute-intensive and therefore derives less benefit from the high-bandwidth unified memory architecture.
These measurements do not yet exploit zero-copy execution paths enabled by unified memory, leaving additional optimization opportunities for future work.
The more significant observation is not the absolute performance, but that a compact desktop system can operate in the same performance range as a datacenter accelerator for memory-bound reconstruction workloads. This suggests that many CT reconstruction pipelines that previously required dedicated cluster resources can now be executed on a workstation-class platform.
Executing supercomputer-sized pipelines on the desktop APU
The more interesting question is not how desktop APU performs on relatively small benchmarks, but whether it can execute reconstruction workloads that traditionally require cluster resources.
To evaluate this, we generated a synthetic Shepp–Logan phantom using TomoPhantom and simulated a dataset comprising:
- Detector width: 2560 pixels
- Detector height: 2140 pixels
- Projection count: 4000
- Estimated peak memory for the full dataset: ~161 GB
This results in a dataset size representative of modern industrial CT acquisitions.
python ./TomoPhantom/Demos/nxs/nxs_generator.py \
--sinogram-shape 2140 4000 2560 \
--output-path ./shepp_logan_2140_4000_2560.nxsExecuting the complete reconstruction pipeline directly on this dataset exceeds the memory available. To address this, we divide the volume into chunks of slices, reconstruct each chunk independently, and subsequently merge the outputs.
Dataset chunking
A wrapper script modifies the HTTomo pipeline configuration to process a subset of slices for each execution.
./chunk.sh \
shepp_logan_2140_4000_2560.nxs \
pipeline.yaml \
chunked_output_dir \
2140 \
300Running the script looks almost identical to calling httomo directly, the last two parameters being the total number of slices and the chunk size, respectively.
Pipeline modification
Chunk boundaries are applied by modifying the pipeline preview section before execution. This is implemented in pipeline_processor.py.
Result stitching
After all chunks have been reconstructed, the resulting HDF5 files are merged into a single output volume using stitch.py
python stitch.py -i chunked_output_dirThe script generates a consolidated stitched_output.h5 file containing the reconstructed volume.
Results
On the target platform, the dataset was processed as a sequence of chunks, with the reported runtime representing the sum of all chunk executions.
For FBP, the dataset was divided into eight chunks: seven chunks containing 300 slices each and a final chunk containing the remaining 40 slices. A 300-slice chunk required approximately 15 GiB of CPU memory during reconstruction.
LPRec required only two chunks: one containing 2000 slices and a second containing the remaining 140 slices. FISTA was executed using the same chunk configuration.
For comparison, the same dataset was reconstructed on a cluster node equipped with two Tesla V100 GPUs. In that configuration, the dataset was divided into two chunks, with reconstruction stages executed in a substantially overlapped fashion.
These results are shown in Table 2:
| FBP [s] | LPRec [s] | FISTA [s] | |
| Tesla V100 (2 GPUs) | 258,226 | 171,396 | 3580,121 |
| AMD Ryzen™ AI MAX+ 395 | 467,818 | 535,384 | 12055,486 |
First, LPRec executes more slowly than FBP on the target platform despite exhibiting the opposite behaviour in the small-dataset benchmark. At present, the reasons for this difference are not fully understood and require further investigation.
One possible contributing factor is pipeline overhead. Although LPRec requires only two chunks, each chunk incurs a separate pipeline instantiation and repeated preprocessing stages. Another potential contributor is the iterative memory estimation procedure used by HTTomo to determine the largest LPRec workload that can safely execute within the available memory budget. Because this estimation is repeated for each pipeline execution, its overhead may become noticeable even when only a small number of chunks are required.
Further profiling will be required to quantify the contribution of these effects and determine whether additional factors are involved. We plan to revisit this topic and optimize the LPRec execution path in a future blog post.
We also evaluated HTTomo’s in-disk execution mode as an alternative to explicit chunking. This approach stores intermediate data on disk and allows datasets that exceed the available memory capacity to be processed without the external chunking and stitching workflow described above. In our initial experiments, however, it did not improve overall execution time, likely due to the additional I/O overhead associated with writing and reading intermediate data.
Nevertheless, in-disk execution remains an interesting direction for future investigation. As the implementation evolves, it may provide a simpler mechanism for processing datasets that exceed available memory while avoiding the operational complexity of explicit chunk management.
Second, although the dual-V100 cluster node remains faster across all workloads, the gap is smaller than might be expected given the difference in hardware class. The reference system consists of two datacenter accelerators operating within a dedicated HPC environment, whereas the target platform is a compact desktop system.
Perhaps the most significant result is not the absolute runtime difference, but that the reconstruction can be executed on a single desktop-class node with 128 GiB of unified memory while remaining within a factor of a few of the cluster-based implementation. For many industrial CT workflows, this removes the requirement for dedicated cluster resources while still providing practical execution times for large-scale datasets.
Summary
These experiments demonstrate that modern tomography reconstruction pipelines have reached a level of efficiency where many workloads traditionally associated with HPC infrastructure can be executed on large-memory desktop APUs.
For FBP and LPRec, performance is broadly comparable to that of a Tesla V100 on the benchmark-sized dataset despite running on a compact mini PC equipped with 128 GiB of unified memory. More importantly, the platform is capable of reconstructing datasets that would traditionally require access to dedicated cluster resources, making it a practical alternative to a reconstruction node for many industrial CT workflows.
The current implementation does not yet exploit the full capabilities of the unified memory architecture. Future work will focus on zero-copy execution paths and other optimizations designed specifically for heterogeneous memory systems, with the goal of further reducing data movement overheads and improving reconstruction throughput.
The Tesla V100, while still widely deployed in HPC environments, was introduced in 2017. Future studies will therefore extend these comparisons to more recent datacenter accelerators to better position modern large-memory desktop systems relative to current-generation cluster hardware.
We also plan to further investigate and optimize the LPRec execution path. In particular, we intend to profile the iterative memory estimation procedure and other pipeline overheads that become visible when processing large datasets.
Finally, we intend to investigate HTTomo’s in-disk execution mode as an alternative to explicit chunking. This approach stores intermediate data on disk and allows pipelines to process datasets that exceed the available memory capacity without requiring external chunking and stitching scripts. Although our initial experiments did not show a performance advantage, likely due to additional I/O overheads, the approach offers a simpler execution model and remains a promising direction for future development.
