
This is not a supplier having a bad quarter. GPU procurement has been permanently redirected. It will not normalise for at least two years.
The AI boom that started in late 2022 did not accelerate GPU demand. It redirected the semiconductor supply chain toward AI compute. NVIDIA's Blackwell data-centre chips are sold out 12 months forward, with hyperscalers ordering in batches of 100,000 units. Amazon, Google, Meta, Microsoft, and Oracle have locked in the majority of what TSMC can manufacture. Not to resell. For their own data centres. By end of 2025, those five companies controlled 71% of all AI compute globally, up from 63% eighteen months earlier.
That pressure hits workstation procurement directly. High-end professional GPUs now carry 12 to 20 week lead times. Memory prices rose 50 to 90% in a single quarter. Dell's COO said the company had never seen costs move at this rate. HP's CEO warned the second half of 2026 will be particularly challenging. Lenovo's CFO called the surge unprecedented.
The upstream bottleneck is High Bandwidth Memory, the stacked memory every modern AI GPU requires. HBM is made by three companies. All three are sold out. The supply-demand gap will not close until 2028 at the earliest. NVIDIA responded by shelving the RTX 5000 Super series and pushing its RTX 6000 release to 2028, creating a three-year hole in the professional GPU product line. It is a deliberate choice about where to direct constrained memory supply.
GPUs are the right tool for the workloads they were designed for. A rasterization pipeline processing a textured polygon mesh at high frame rates, running complex lighting and shadow calculations across millions of uniform triangles, is operating in its element. The data is uniform, the parallelism is total, the access patterns are predictable.
Point cloud data is the structural opposite.
A point cloud is a collection of XYZ coordinates from a sensor, each with intensity values and often RGB colour data. Processing it at scale requires spatial queries: find all returns within a given distance, identify nearest neighbours, determine which are visible from the current view. The problem is the nature of the data itself: sparse, irregular, with no predictable runs of contiguous fragments for parallel threads to work through efficiently. A triangle mesh has clean, uniform structure that maps naturally to GPU pipelines. A point cloud does not. These operations traverse tree structures, require conditional logic, and involve scattered memory access, exactly the conditions under which GPU parallelism breaks down.
Precision compounds the problem. Geospatial coordinates span millions of metres and cannot be represented exactly in the 32-bit floating-point format GPUs prefer. GPU renderers rebase coordinates per tile as a workaround. Modern GPUs can perform 64-bit double precision calculations, but on professional-grade cards that delivers roughly half the throughput of their native 32-bit path, and on workstation-class cards as little as 1/32, making it impractical for production workflows at scale. CPU-based renderers use 64-bit double precision natively, with no performance penalty. For survey work where millimetre accuracy matters across kilometre-scale datasets, that difference is not academic.
Where GPUs retain advantages: when a dataset fits within VRAM, a high-end GPU with optimised compute shaders achieves higher frame rates. For applications requiring 60-plus FPS with photorealistic rendering, GPU rasterization is the right choice. Deep learning on point cloud data runs 5 to 10 times faster on GPU for equivalent batch sizes. For that workload, GPU is the right tool.
The architecture was mismatched before the shortage. The shortage made the cost of staying with it visible.
Modern professional GPUs carry 24 to 48 GB of VRAM. That is a ceiling. When a point cloud dataset exceeds it, the software has two options: refuse to load the data, or thin it out until it fits. Every major GPU-dependent tool in the market chooses the second option. The dataset must be decimated, downsampled, or tiled before it can load, then LOD is applied on top of that already-reduced data. Your analyst works with a fraction of what the sensor captured.
This is not a bug. It is the architecture working as designed. Every tool in the market, including Unlimited Detail, requires a conversion or indexing step before data can be rendered. The question is what that step does.
The dominant GIS desktop platform shows performance degradation beyond 50 to 100 million points without decimation. The most widely deployed open-source point cloud tool recommends decimation and spatial cropping for datasets exceeding 50 million points as standard practice. In each case, preprocessing exists to reduce the data to fit the architecture's constraints.
Unlimited Detail's conversion step works differently. Rather than discarding data to fit a memory ceiling, it builds a spatial index that allows the engine to stream only what the current view requires. The full dataset is preserved at full resolution. The preprocessing serves the data. It does not compromise it.
CPU-native rendering does not try to load the dataset and render what fits. It asks a different question: for the current camera position and screen resolution, which points need to be drawn? A GPU renderer asks the same question. The difference is that a GPU can only answer it from what has already been loaded into VRAM. Unlimited Detail answers it from the full dataset, regardless of size, streaming only what the current view requires.
On a 4K display, the answer is 8 million points. That is the number of pixels on the screen. No matter how large the dataset, the display can only show 8 million distinct values at any moment.
A 50 TB dataset and a 500 GB dataset both load in under 20 MB and render at interactive frame rates. Performance is tied to screen resolution, not dataset size. As the user navigates, the engine fetches only what the display can show.
Instead of discarding data to fit a memory ceiling, Unlimited Detail builds a spatial index that allows the engine to stream only what the current view requires. The full dataset is preserved at full resolution. The preprocessing serves the data. It does not compromise it.
Minimum hardware: 4-core CPU, 8 GB RAM, SSD. Recommended: 8-core CPU, 16 GB RAM. No GPU at any scale.
Raw data conversion: 360 GB of LAS/hr for datasets under 20 GB, 200 GB/hr for larger files. On server-grade hardware with fast disk access and higher core counts, conversion can exceed 1 TB per hour.
The analyst sees exactly what the sensor captured.
The Unlimited Detail™ engine powered the Leica Geosystems JetStream product line at enterprise scale, serving more than 30,000 users. The technology carries granted patents and more than twelve years of production development.
The US Navy runs a CPU-native 3D digital twin on a classified, air-gapped network. The hardware is a standard Dell Latitude laptop with no GPU. That is a paying production deployment, not a pilot. Cloud tools are not an option. The CPU-native approach runs on existing government-issue equipment, with no external network dependency and no licensing that calls home.
The Queensland Government runs more than 171,000 datasets through a CPU-based geospatial platform. A tier-one US defence prime is integrating the rendering engine into an operational command and control platform.
CPU-native rendering removes that ceiling, runs on commodity hardware, and puts the full dataset in front of every analyst, not just the ones who drew the GPU workstation in the procurement lottery. The sensor data your team paid to capture finally reaches everyone who needs it.
A 10-analyst geospatial team running GPU-dependent tools carries a five-year total cost of ownership of USD $275,000 to USD $505,000. That figure covers GPU workstations at USD $5,000 to USD $20,000 per seat replaced every three to four years, annual software licences at USD $3,500 to USD $6,500 per seat per year, and cloud GPU overflow compute at USD $3 to USD $15 per hour.
The same team on CPU-native tools carries a five-year TCO of USD $13,000 to USD $35,000. Commodity CPU workstations, standard software licences, CPU cloud instances at USD $0.50 to USD $1.00 per hour.
The ratio is 10 to 20 times lower. In the current procurement environment, where GPU workstations are harder to source and more expensive than at any point in the past decade, that ratio widens further.
Standard CPU hardware ships through Dell, Lenovo, and HP business channels with 4 to 8 week delivery windows. The team deploys in weeks, not the 9 to 12 months a GPU procurement queue now demands.
Geospatial processing firms gain a further advantage. CPU cloud instances run at 20 to 100 times lower cost than GPU equivalents for point cloud workloads. Take that as a pricing wedge against competitors or fold it into margin.
The GPU shortage and the VRAM architecture problem are not separate issues with a shared solution. The industry built its geospatial tools around GPU hardware designed for polygon rendering, priced for enterprise budgets, and available on standard lead times. All three assumptions broke in the same year.
The architectural mismatch predates the shortage. The VRAM ceiling was a constraint before NVIDIA shifted its roadmap. Decimation was standard practice before memory prices rose 90% in a quarter.
The shortage makes the case urgent. The architecture makes it correct regardless of when supply recovers.
Before your next procurement cycle, one question:
How much of the data your sensors captured last month did your analysts work with?
Kristian WaresCEO and Co-Founder, Nuclideonkwares@nuclideon.comnuclideon.com
Nuclideon Pty Ltd renders datasets exceeding 200 TB in real time on standard CPU hardware, with no GPU dependency. The Unlimited Detail™ engine is patented technology. Paying customers include the US Navy, Lockheed Martin, and the Queensland Government.