The catch: there's no VRAM to install into
The test machine was a Lenovo Yoga 9n Gen 11 with 64GB of memory. A typical gaming laptop has separate system RAM and VRAM. The RTX Spark doesn't. NVIDIA's documentation says the CPU and integrated GPU share the same physical memory.
NVIDIA's Windows on Arm porting guide splits that pool into three logical regions:
- Dedicated GPU memory (carveout): reserved for the iGPU and reported by Windows as dedicated GPU memory.
- Shared system memory: managed by Windows and accessible to both the CPU and the iGPU.
- CPU-only system memory: the remainder, which can't be used for GPU allocations.
NVIDIA says the carveout is physically backed by system DRAM rather than separate VRAM, but it plays the same role as VRAM on a discrete GPU. So "installing Crysis on the GPU" has no clean meaning here. The memory is the same silicon whichever label Windows puts on it.
NVIDIA also publishes the sizing rule for the rest of the pool. The nominal shared size is the post-carveout capacity minus 16GB, clamped to between 50% and 80% of that capacity. The author's machine-specific numbers below are his own readings, not NVIDIA's.
The slider, and what it costs Windows
The author says the Nvidia app has a slider that sets the GPU's share of the 64GB pool. On his unit it goes as low as 4GB for the GPU, and every change needs a restart. Task Manager shows the reservation as "Dedicated GPU memory", as it would for a discrete card. The Memory tab folds it into "Hardware reserved".
His measurements show the tradeoff plainly:
- At a 48GB GPU / 16GB Windows split, Windows had only 30.3GB available. That was after he quit Ollama and shut down WSL, which freed about 1.6GB.
- At 56GB / 8GB, available memory rose to 38.1GB. The hardware-reserved figure fell from 17.2GB to 9.2GB.
- At one point he saw only 30.8GB because he'd left the slider at 32/32 from an earlier test.
These readings come from one laptop, and background load and firmware reservations will shift them. The lesson holds generally: on a fixed unified pool, every gigabyte handed to the GPU is a gigabyte Windows apps can't use.
Other reporting suggests the default carveout varies. XDA's Blender test on a different RTX Spark laptop mentions a 64GB default, and a WindowsForum report on that test says the carveout can be raised to 96GB in the Nvidia app. NVIDIA's own guide, according to one third-party analysis, doesn't publish a carveout size. Check your own unit's setting rather than assuming a default.
How the RAM disk was built
The author used SoftPerfect RAM Disk. Not relevant here; the product's own page lists ARM64 support as follows: it works on Intel, AMD and ARM64 processors, and it offers both persistent RAM disks and volatile ones whose content disappears on shutdown. He made a 23GB volatile disk on R:, about 15% larger than the 19.9GB install. Everything on it is lost on reboot.
To keep the EA app happy, he did this:
- Renamed the real install folder on the SSD.
- Copied it to
R:withrobocopy. - Created a directory junction at the original path:
cmd /c mklink /J "C:\Program Files\EA Games\Crysis Remastered" "R:\Crysis Remastered"
Microsoft's documentation lists /j as the mklink switch that creates a directory junction. The EA app still believes the game lives in Program Files, but reads land on the RAM disk.
Two practical cautions follow. The RAM disk is wiped on restart, so the game must be recopied (or the disk made persistent) before the junction points at anything. And moving a launcher-managed install around is an experiment, not a recommended setup.
Proof that reads came from memory
Resource Monitor's Disk tab showed reads from R:\Crysis Remastered\Engine\Shaders while the title screen loaded. At the pause menu, Task Manager showed 42.5GB of 54.8GB in use and 12.2GB free, with the SSD at 2% activity. The author played part of the first level, saved and reloaded, and says it behaved like a normal install. These are his observations, not a controlled benchmark.
The SSD still got a look-in: Prism's cache
The surprise was reads from C:\Windows\XtaCache, including a cached translation of NVNGX_DLSSG.DLL used by CrysisRemastered.exe. That fits how Windows on Arm works. Microsoft's documentation says emulation translates blocks of x86 instructions into Arm64 code and that a service caches the translated blocks to cut translation overhead on later runs. Prism is the emulator in Windows 11 24H2. Microsoft also notes that emulation covers user-mode code only, so kernel components must be Arm64.
So moving the game folder doesn't remove the SSD from the picture. Even on an Intel or AMD PC, Windows and driver files would still load from C:. The translation cache is the Arm-specific wrinkle.
The author also installed the original 2007 Crysis as a backup, and it launched under Prism. That is a separate game from the one on the RAM disk.
The benchmark numbers
He ran CrystalDiskMark's Arm64 build with three passes and a 1GiB file. His SSD was 89% full. All of these are read results he reported:
| Test | Internal SSD (MB/s) | RAM disk (MB/s) | Ratio |
|---|---|---|---|
| SEQ1M Q8T1 | 7,293 | 28,763 | 3.9x |
| SEQ128K Q32T1 | 4,563 | 11,443 | 2.5x |
| RND4K Q32T16 | 1,252 | 3,817 | 3.0x |
| RND4K Q1T1 | 30.9 | 1,241 | 40x |
The bottom row matters most. Single-threaded 4K random reads are latency-bound, and the RAM disk wins by 40x there. The sequential figure of about 28.8GB/s is well below the memory's rated 300GB/s. The author suspects the RAM disk software and the CPU are the limit, which is a reasonable reading but not something he proved.
He deliberately didn't time load screens, so these numbers don't show faster gameplay or shorter loads. A random-read score of 1,241MB/s doesn't convert into a gaming gain.
What this does and doesn't show
- It shows game files can be served from a RAM disk in the unified pool, and Resource Monitor can confirm it.
- It doesn't show the GPU hosting the files in a separate VRAM device. On the RTX Spark there isn't one.
- It doesn't show a performance benefit for gaming.
- It does show a real memory-budget tradeoff for anyone tuning the carveout slider.
Memory budgeting is a live concern on this platform. NVIDIA's guide warns that Windows limits the GPU budget because exposing too much system memory to the GPU can starve the rest of the system. It also says allocating the full GPU budget can leave too little host memory and make the system unresponsive. A big RAM disk on top of a big carveout squeezes Windows from both sides.
On the useful end, the author says that on a 128GB machine he'd consider a RAM disk for scratch space. That fits SoftPerfect's own suggestions of compiler output and database tempdb. NVIDIA lists up to 128GB for RTX Spark, but a 64GB unit like this one has far less headroom.
Bottom line
The answer to "can it run Crysis from GPU memory?" is "sort of, depending on your definition of GPU memory." It's a quirky test, but it makes the unified-memory model concrete: one pool, a slider, Windows accounting that renames the same DRAM, and an emulation cache that keeps touching the SSD. Treat the speed numbers as one tester's results, and keep the RAM disk for throwaway data.