The test is a capacity demonstration, not a speed contest, and Conway says so himself.
What was tested
HP supplied Conway with the top OmniBook Ultra 16 configuration. XDA lists it as follows:
- a 20-core Grace CPU
- a 6,144-core Blackwell GPU
- 128GB of LPDDR5X-9400, shared over a 256-bit bus at 300GB/s
- a price of $6,229.99 on HP's store
Nvidia's launch announcement confirms the platform and lists HP's OmniBook Ultra among the launch laptops. Blender has released a beta version of its popular 3D editor, adding compatibility for RTX Spark. Per XDA, Windows-on-Arm CUDA/OptiX rendering arrived in the Blender 5.3 beta. Blender's own commit history shows the groundwork. Blender had been built with CUDA features disabled when targeting Windows ARM64. The patch enables the CUDA and OptiX Cycles devices by default when targeting Windows ARM64, just like Windows x64.
Blender 5.3 is not final yet. Blender's release page lists an expected date of November 10, 2026. Anyone repeating the test today needs the beta.
Why "128GB" is not all GPU memory
Unified memory does not mean Windows treats the 128GB as one pool. Nvidia's Windows-on-Arm porting guide describes three logical regions over the same physical DRAM:
- Dedicated GPU memory (the carveout): reserved for the integrated GPU and reported by Windows as dedicated GPU memory. It is backed by system DRAM, not separate VRAM, but it plays the same role as VRAM.
- Shared system memory: managed by Windows and usable by both the CPU and the GPU.
- CPU-only memory: the remainder, which the GPU cannot allocate from.
After the carveout, the nominal shared size is the leftover capacity minus 16GB. That value is clamped to between 50% and 80% of the leftover capacity.
Conway says the carveout can be raised to 96GB in the Nvidia app. He left it at the 64GB default. CUDA allocations use the carveout first and then spill into shared memory. He also says Nvidia credits the dedicated region with larger memory pages and other driver optimizations, so shared allocations can still be slower.
The practical lesson is that a laptop's headline RAM figure and the memory a render can actually use are different numbers, and the carveout setting matters.
A local LLM wrote the scene
Conway ran Qwen3.8 Flash Next locally through llama.cpp, with a 262K context window. He used an Nvidia-published recipe built on Unsloth's IQ4_XS quantization. XDA describes the model as having 125 billion parameters, of which a mixture-of-experts design activates six billion per token, at up to 45 tokens per second. These model details are XDA's and were not independently confirmed.
He connected the model to Pi, a minimal coding agent. He asked for an abandoned futuristic city with roads, industrial structures, vehicles, vegetation and dusk lighting. The model was told it shared memory with Blender. It was to test at low detail first and then produce a standalone PowerShell script for the final renders, to be run with the inference server shut down.
According to the report, the first full-size Cycles render arrived about 81 minutes after the prompt, with no intervention from Conway. Along the way the model:
- found Blender in the Downloads folder
- verified that OptiX worked
- wrote the scene generator
- refined it by rendering and inspecting previews
The result was a Python script of just over 700 lines using Blender's bpy API. At full scale it builds the following:
- a 15-by-15 grid of blocks spaced 170 metres apart
- about 13,600 objects
- 24 tower designs
- 60 vehicles, 15 of them overturned
- 380 trees
- a fallen 110-metre communications tower
It also generated 18 camera positions by finding landmarks in the scene.
Why the scene got so big
Every building carries a subdivision modifier followed by a noise-driven displacement modifier. Each subdivision level roughly quadruples the face count. The .blend file stayed under 2MB at every setting, because the extra geometry is created when Blender evaluates the scene. Conway attributes most of the GPU memory use to that evaluated geometry and OptiX's ray-tracing acceleration structures.
The render script polled nvidia-smi every half-second to log baseline and peak memory. On RTX Spark those numbers reflect the dedicated carveout, so they are broadly comparable to discrete-card VRAM. Baseline with the LLM shut down was about 1.3GB.
| Detail setting | Evaluated vertices | Peak scene memory | 1080p render time |
|---|---|---|---|
| Level 4 | 6.65 million | 6.7GB | 10–17 seconds (48 samples) |
| Level 6 | 106.3 million | 38.4GB | 6.5 minutes (16 samples) |
| Level 6 plus 11% of buildings at level 7 | 139.3 million | 49.3GB | 12 minutes (64 samples) |
At the top setting, total reported usage was 50.6GB. Five different 1080p shots at 64 samples varied by less than 70MB in peak memory.
A 16-sample render still took more than 11 minutes. Conway reads that as most of the time going to geometry preparation and acceleration-structure building, not to tracing samples. That is his interpretation, not a profiled result. The fans ran flat out throughout.
What this does and doesn't prove
Conway is explicit that the RTX Spark is not faster than an RTX 5090. The 5090's 1,792GB/s of memory bandwidth is nearly six times the Spark's 300GB/s. For scenes that fit in 32GB, the desktop card should be faster. The Spark's advantage is capacity.
The comparison has caveats:
- A desktop 5090 might still finish. Cycles can fall back to system RAM when GPU memory fills. Some data cannot be moved out of GPU memory, though, and Cycles fails if what remains does not fit.
- The PCIe contrast is theoretical. PCIe 5.0 x16 peaks at roughly 64GB/s per direction, against the Spark's 300GB/s. Those are peak bandwidths, not application speeds.
- Pricing is XDA's. The report puts a 72GB RTX PRO 5000 at $9,999 and says the 96GB RTX PRO 6000 Blackwell can cost up to twice that. It notes that this is more than the whole laptop costs.
- Rivals exist. XDA mentions AMD's Strix Halo, which offers up to 128GB of unified memory and Blender acceleration through HIP but no CUDA or OptiX. It also mentions Apple's M5 Max, which has considerably higher bandwidth.
Nvidia's own announcement markets RTX Spark for rendering 3D scenes of 90GB and larger, even when unplugged. That is a vendor claim. XDA's 49.3GB measurement is a different and more modest data point, and it sits well inside the 64GB default carveout.
Practical takeaways
- Check the carveout in the Nvidia app before a heavy render. It sets the ceiling for dedicated GPU memory.
- Use Blender 5.3 beta, or the final release once it ships, for CUDA/OptiX on Windows on Arm.
- Develop at low detail and watch peak memory with nvidia-smi. Scene complexity can rise very fast when subdivision levels stack.
- Stop the local LLM server before the final render. Both workloads draw on the same physical memory.
- Expect long frame times and loud fans on sustained work.
For artists and developers whose scenes outgrow gaming-card VRAM, this is an early sign that large unified-memory Windows laptops can handle jobs once reserved for workstation cards. Wider independent testing will show how far that holds beyond a single procedurally generated city.