Introduction
The planetary stereophotogrammetry and high-resolution surface modeling work I do requires compute resources that span traditional workstation, server, and mobile platforms. Large institutional teams can use, or provide access to, shared clusters or centralized HPC environments. Postdoctoral scientists, graduate students, and small-team investigators often have to assemble and optimize their own compute workflows in order to remain productive.
This post examines a practical, multi-system approach to planetary geospatial processing, focusing on the performance of specific software: Ames Stereo Pipeline (ASP), Agisoft Metashape Professional (Pro), and any interactive Geographic Information System (GIS). Rather than benchmarking a single “best” machine, my goal is to understand how different hardware architectures, such as server-class CPUs, GPU-accelerated desktops, and high-end mobile systems, actually perform under real production constraints. How can these systems be combined effectively within a single research workflow without breaking the bank? What is the most cost-effective solution given the task, or more realistically, several overlapping tasks, for researchers like me who usually have a few irons in the fire at once?
This analysis is grounded primarily in theoretical architectural behavior and operational considerations, but it is intended to be backed up with hands-on testing as these systems are brought into regular use. I am deliberately not relying solely on synthetic benchmarks. I pay particular attention to memory bandwidth, CPU core scaling, GPU utilization, and sustained throughput, since these factors tend to dominate wall-clock time for large digital terrain model (DTM) production and dense photogrammetric reconstruction. The goal is to arrive at a framework for matching workloads to hardware in a way that maximizes productivity without assuming access to institutional HPC resources. I also summarize costs, which matters more than usual right now. As of mid-December 2025, memory prices are roughly four times higher than recent norms, driven largely by demand from large data center deployments. This happens at a very inconvenient time when I need to upgrade because my computers are aging, must meet higher demand, and Windows 10 is no longer supported. My “laptop situation” is also dire. I don’t hate new hardware! However, new hardware is expensive. How can I economically meet my computing performance demands? A high powered laptop would give me more clock cycles and portability, but will it stack up?
Systems Comparison
Photogrammetry and stereo pipelines place fundamentally different demands on compute hardware depending on scale, parallelism, and software architecture. I already have a a GPU-accelerated Ryzen desktop that I built earlier this year. I got a 32 GB DDR5 memory kit for only $192. (Ah, the good ol’ days.) I was considering two Linux systems alongside perhaps a copy of my existing desktop and below is a comparison of specs based on what I could find about all the components:
- A server-class AMD EPYC workstation
- A GPU-accelerated Ryzen desktop
- A high-end System76 Oryx Pro laptop
Table 1. Summary of hardware platforms considered in this analysis.
| Category | EPYC 7702 Workstation | Ryzen 9 7900X Workstation | System76 Oryx Pro (oryp13) |
|---|---|---|---|
| OS | Ubuntu 24.04.2 LTS | Ubuntu 24.04.2 LTS | Pop!_OS / Ubuntu 24.04 |
| CPU | AMD EPYC 7702 | AMD Ryzen 9 7900X | AMD Ryzen AI 9 HX 370 |
| Architecture | Zen 2 (Rome) | Zen 4 | Zen 5 (mobile) |
| Cores / Threads | 64 / 128 | 12 / 24 | 12 / 24 |
| Base / Boost | 2.0 / 3.35 GHz | 4.7 / 5.6 GHz | 3.0 / 5.1 GHz |
| L3 Cache | 256 MB | 64 MB | 32 MB |
| Memory | 128 GB DDR4 ECC RDIMM | 128 GB DDR5 | Up to 96 GB DDR5 |
| Memory Channels | 8-channel | 2-channel | 2-channel |
| Sustained Memory BW | 170–180 GB/s | 70–80 GB/s | 60–70 GB/s |
| GPU | None | 2× RTX 3090 (24 GB) | RTX 5070 Laptop |
| PCIe | 128× Gen4 | 24× Gen5 | Mobile-limited |
| NVMe | SlimSAS Gen4 | M.2 Gen4/5 | 2× M.2 Gen4 |
| NVMe topology | Direct CPU lanes | CPU + chipset lanes | – – |
| Thermal Environment | Server-class sustained | Desktop sustained | Laptop-constrained |
I really like the laptops I saw from System76 specifically because of their Linux OS and AMD CPU offerings. I decided spec out the Oryx Pro because it looked about as close as I could get to the performance of a desktop but still maintain the portability characteristics I would want. I liked my Microsoft laptops, but I wanted to try something different and more aligned with my Linux-based workflow. I replaced Windows with Ubuntu on an inexpensive ASUS laptop, and I like where that was going. [Just to get it out of the way, I’m always had a preference for PCs, so I’m not considering Apple desktops or laptops.] For simplicity, I’m going to lump Metashape and GIS together because I think the interactive performance outcome for both software packages would be effected similarly by the hardware selections. Metashape can be configured to take advantage of multiple GPUs, there is really no contesting the desktop setup above by the other two systems. This is what the overall performance expectation looks like:
Table 2. Expected relative performance of Metashape Pro steps.
| Stage | EPYC 7702 | Ryzen + 2×3090 | Oryx Pro |
|---|---|---|---|
| Image alignment | Slow | Fast | Fast |
| Depth maps | x | Extremely fast | Fast |
| Dense cloud | x | Extremely fast | Fast |
| Mesh | Slow | Fast | Moderate |
| Texture | Slow | Fast | Moderate |
| Sustained runs | N/A | Excellent | Thermally throttled |
| Rank | 3rd | 1st | 2nd |
The Oryx Pro would be a solid laptop and a pretty good portable Metashape processing arm, and because of the multi-core CPU, I could multitask while running jobs. With a minimum of 64 GB RAM added to the system, the price would be $3500 and $3750 maxed out at 96 GB. My desktop total cost was kept under control at < $4k. You can still get the Founder’s Edition RTX 3090 GPUs at a good price on eBay (December 2025), but the memory inflates the cost of another desktop build by $2300. Price alone ruled out another Ryzen system, and if Metashape was all I was considering, the server-class AMD EPYC workstation is obviously ruled out. I could order my laptop and wrap up this post, but I’ve been using a completely different tool lately: the Ames Stereo Pipeline (ASP). A combined laptop & “ASP processing mule” isn’t going to cut it.
I’m been using ASP to build digital terrain models (DTMs) using pairs of images from the Mars Reconnaissance Orbiter Context Camera (CTX). This process leverages the multiple cores in the CPU, not GPU, leveraging parallelized computing. ASP is selectively memory-bandwidth intensive. The most memory-intensive process is stereo matching using parallel_stereo. Correlation involves repeatedly sliding a window across left and right rectified images, reading large amounts of pixels, reading and writing tiles, per-pixel caching, and multi-threaded tile processing. For CTX, images can exceed multiple GB, requiring the processing of millions to billions of pixels.
My Ryzen system is only a 2-channel desktop and therefore is memory-bandwidth bound. Other steps that consume memory and bandwidth include SGM/MGM algorithms, filtering and disparity cleanup, and point2dem. The image normalization, key point detection, bundle adjustment and the pc_align don’t stress the system too much as single core, serial processes. Considering full-pipeline performance, the memory-bound stages dominate runtime, especially for large DTMs.
Table 3. ASP stages and their resource demands.
| Stage | Memory-bound? | Notes |
|---|---|---|
| Correlation (parallel_stereo) | Strongly yes | Main overall performance |
| SGM/MGM cost aggregation | Strongly yes | One of the most bandwidth-demanding in computer vision |
| Filtering/subpixel | Moderately yes | Low arithmetic intensity |
| point2dem | Sometimes yes | – – |
| bundle_adjust | No | Compute-bound |
| pc_align | Mostly not | Compute/latency-bound |
| Preprocessing | No |
From my experience using an array of decent laptops and desktops, I could only expect a system to process one DTM at a time using stereophotogrammetry software, whether that is a multi-view stereo job in Metashape Pro or a planetary image correlation using ASP. Even with my highly spec’d 12-core/24-thread Ryzen desktop, I have found that I’m really only productive doing less intensive tasks (GIS, coding, writing, etc) while running ASP or Metashape in the background. Even if I had a second Ryzen desktop-class CPU (I’d love a Threadripper), I could really only manage ASP to process a second DTM synchronously, maybe a third. How do I get the biggest bang for the buck?
Why EPYC for ASP?
More cores; more threads.
The AMD EPYC 7702 is a powerful 2nd Gen “Rome” 64-core, 128-thread server processor that was first introduced in 2019. If found it at an extremely attractive $500, originally retailing for $7k and still goes for $725 online. It’s been used for data centers needing massive core counts and bandwidth and is known for excellent multi-threaded performance in AI or HPC setups. The EPYC goes in a SP3 socket, so it won’t just slip into a consumer-grade motherboard. If my Ryzen 9 7900X is a baseline with dual-channel DDR5 memory, the high throughput of the EPYC 7002’s eight memory channels is expected to perform 2-3 times faster for a single ASP run and 4-5 times faster processing multiple pairs at once. The next step up might be an EPYC 7742, but this is only 10-15% faster for twice the price.
To make budget, I made use of second hand markets. Like a racing car in an F1 race, CPUs, memory, motherboards, and more are swapped out of server farms and data centers to keep their edge and everyone’s online orders rolling. I really didn’t like what I was seeing online and I was nervous about buying from anyone on eBay. I learned a lot. Did you ever hear of someone opening up an SSD only to find it “light” and a thumb drive wired up in its shell? For example, many cheap second hand chips on the market are engineering or quality control samples (ES/QS) and won’t boot in some boards. Others might be OEM-locked and will only boot in the manufacturer’s server board. Counterfeit labels, polished and repackaged dies, untested, and no meaningful return policy. Although eBay has a good guarantee and return policy, I really didn’t want to deal with a chip DOA. Some of these chips have been running at peak for 3-5 years in a server. That’s a lot of risk, some of which I can’t avoid. I wanted a reputable U.S.-based seller/refurbisher with fair pricing, at least a 30-day warranty, verified production listings, and no OEM-locks.
Motherboard selection was a tougher task. I wanted a Supermicro H11SSL-i, but everything I found was sold overseas. Although the country of origin might not be an issue, I wasn’t going to pay $230 for shipping. The list of motherboards to avoid was LONG. I finally converged on the Asrock ROMED4ID2T Desktop Motherboard; hopefully at build time, I come out on top. This board is rare delivering full EPYC Rome memory bandwidth in a very small desktop form factor. It only has a VGA output, but I’m not planning on using it as a desktop. The Mini-ITX server-class motherboard specs look awesome:
- AMD EPYC 7702 (Rome) processor support
- 8-channel DDR4 RDIMM
- PCIe Gen4
- Dual 10Gb Ethernet
- 6× SATA ports
- 1× PCIe Gen4 ×16 slot
- Slimline connectors for high-bandwidth storage using NVMe drives
More caveats included the right size case, proper cooling, and supporting memory or registered (RDIMM). Memory availability and pricing were a real constraint. I ended up getting RAM from a reseller that didn’t even have it advertised. As soon as it’s visible online, it gets snatched up. I settled on less RAM than I would a year ago, but that’s fine. Theoretically, DDR4 RDIMM is a liquidation commodity as DDR5 steps in. The large supply of DDR4 supply should be pulling price downs, but demand and resulting shortage of DDR5 keep the DDR4 price high and a “premium” in the market. It’s also Christmas. I decided to drop to 16 GB per stick for this platform. It was more important to me to maximize all 8 memory lanes to get maximum bandwidth, which still yields 128 GB. Oh darn.
On a EPYC workstation, everyday uses (application launches, web browsing, python single-thread processing, GIS tools, Blender, etc) might feel slower than the Ryzen desktop. However, the EPYC’s function will be a dedicated ASP production server. This is the build of materials:
- Seasonic Focus GX-750 – $119
- ASRock Rack ROMED4ID-2T – $607
- AMD EPYC 7702 – $500
- Samsung 16GB 1Rx4 PC4-3200A RDIMM ×8 = 128GB – $1,160
- Fractal Design Node 804 – $164
- Noctua NH-U9 TR4-SP3 CPU air cooler – $139
- Micro SATA Cables SlimSAS 4i to M.2 NVMe Adapter – $73 ×2
- Micro SATA Cables SFF-8654 4i → 4i, Gen4, 50cm – $41 ×2
- Samsung 990 EVO 2TB – $177 ×2
Because ASP is CPU-dominated, it should scale with cores and memory bandwidth and perform best as my primary production machine for processing CTX DTMs of large regions and batch processing. The laptop option would produce a DTM at a moderate speed, but it doesn’t fit my use case. Here is a side-by-side comparison of the server and desktop options in terms of expected ASP performance.
Table 4. Expected ASP relative performance comparison.
| Aspect | EPYC 7702 server | Ryzen 7900X desktop |
|---|---|---|
| Optimal threads per DTM | 24-32 | 12-16 |
| Memory stalls | Low | Moderate-high |
| Correlation efficiency | Sustained | Drops early |
| L3 cache stress | Low | Moderate |
| Single-thread steps | Slower | Much faster |
| Multi-thread steps | Much faster | Slower |
| Memory-bound stages | Massively faster | Bottle necked |
| Large DTMs | Excellent | Struggles earlier |
| Wall-clock time (large DTM) | Shorter | Longer |
| Stability at scale | Very high | Moderate |
| 1 DTM | Fast | Fast |
| 2 DTMs | Very efficient | Slows sharply |
| 3 DTMs | Still efficient | High RAM and virtual memory swapping high |
| 4+ DTMs | Stable | Unusable |
| parallel_stereo, SGM/MGM | Better, 2-3x faster | Fewer cores & 2-channel RAM |
| Tile-based DEM generation | Better, 2x faster | High throughput requirement |
| point2dem | Better, 2x faster | parallel & memory heavy |
| pc_align (large point clouds) | Good thread scaling | – – |
| Bundle adjust (large DTMs) | Thread + cache advantage | – – |
| Bundle adjust (small DTMs) | – – | High single-core boost |
| Aggregate throughput / rank | 1st | 2nd |
Everything about the EPYC server looks amazing, except the relative single-thread performance due to its lower clock speed. I had to realize that a single thread doesn’t mean a single job. A single DTM job in ASP involves 10s of worker threads spawned by parallel_stereo, and each thread is doing memory intensive correlation steps, heavy cache reuse, sustained memory bandwidth, and run times could be are hours to days. CPU clock speed is simply not the limiting factor.
Summary and Conclusion
If I step back from individual components and benchmarks, the main lesson I learned from this exercise is that no single system is well suited to every stage of planetary geospatial processing. ASP, Metashape, and interactive GIS place fundamentally different demands on hardware, and attempting to force all of those workloads into a single box inevitably leads to compromise. In my case, those compromises would have shown up as long ASP runtimes, idle GPUs, or a laptop pushed far beyond what it can reasonably sustain.
What will ultimately make the EPYC system compelling is not peak clock speed or theoretical performance, but the ability to sustain throughput across memory-intensive workloads and to scale efficiently when running more than one DTM at a time. For ASP, the limiting factor is not a single fast core, but the ability to keep many worker threads supplied with memory bandwidth for hours or days at a time. Once I framed the problem that way, the appeal of a server-class CPU with eight memory channels became obvious, even if it might feel slower for everyday desktop tasks.
My Ryzen desktop remains the clear choice for GPU-accelerated work and interactive analysis. Metashape Professional, GIS workflows, debugging, and exploratory processing benefit from high single-thread performance and powerful GPUs, and that system already does those jobs extremely well. A laptop would fill a different role entirely. It is not a replacement for either desktop or server hardware, but it provides portability and flexibility when work has to move out of the office or when smaller jobs need to run without tying up primary systems.
The broader takeaway is that optimization, at least for an independent researcher, is less about finding the fastest machine and more about matching the right hardware to the right task. I should have probably learned this a long time ago from a fellow graduate student in my lab. He was a computer science expert, and he would get his work done on a budget laptop. By separating throughput-heavy processing from GPU-heavy and interactive work, it is possible to get more total productivity out of a collection of modestly priced systems than out of a single, expensive all-purpose machine. This approach is not unique to planetary science, but it is particularly relevant as datasets grow, budgets tighten, and access to shared HPC resources remains uneven.
This analysis represents a starting point rather than a final answer. As my new server comes online and sees real-world use, measured runtimes and practical bottlenecks will refine or challenge some of these expectations. Still, the architectural principles discussed here are unlikely to change. Memory bandwidth will continue to matter for stereo correlation. GPUs will continue to dominate dense reconstruction and AI infrastructure. And thoughtful division of labor across systems will continue to beat one-size-fits-all solutions.
Status and Future Work
At the time of writing, the EPYC-based system described here has been fully specified and components have been acquired, but the system has not yet been assembled and benchmarked. The performance comparisons and expectations discussed in this post are therefore based on architectural analysis, documented software behavior, and prior experience with similar systems rather than direct wall-clock measurements on this specific build.
A follow-up post will document the build process, configuration choices, and measured performance for representative ASP workflows once the system is operational. Those results will either validate or challenge the assumptions outlined here, and will help refine this multi-system approach based on real usage rather than expectation alone.
Note for early-career researchers: This analysis reflects how I am thinking through hardware choices under real constraints, not a finished benchmark study. The EPYC system described here has not yet been built or tested, and performance expectations are based on architectural reasoning and prior experience. A future post will share measured results once the system is operational.