What if video memory could be used as regular RAM?

The logical solution would be to buy an extra RAM stick. But there's a catch: one slot on the motherboard is occupied, and there's simply no second one. Laptop. (Though if I'm being honest, even if there was a free slot, it's not a given that I'd have the money for an extra stick right now anyway.)

So there I am, staring at the Task Manager: the RAM is completely maxed out, while my graphics card with its 6 GB of VRAM is sitting on the sidelines doing nothing. No heavy graphics work, it's just sitting idle.

That's when the question popped into my head: is it possible, at least theoretically, to use video memory to expand the available RAM?

Why "Instead of RAM" Is Already the Wrong Phrase

Let me state this upfront, otherwise I'll get a flood of "the author has no idea what they're talking about" in the comments.

The CPU accesses regular RAM directly, via the memory controller that's built right into the CPU die. The latency is around 70 nanoseconds. That's extremely fast.

VRAM is physically located on the graphics card, on the other side of the PCIe bus. For the CPU to access a single byte of VRAM, it has to assemble a transaction, send it through the PCIe slot, wait for the GPU to respond, and then fetch the data back. That process takes microseconds, which is orders of magnitude slower.

On top of that, you can't store page tables in VRAM, and the CPU can't decode instructions from it at a normal speed. So using VRAM as RAM in the literal sense? No, that won't work.

But there's another related idea that's actually viable: using VRAM as a very fast swap space.

Swap — The Thing That Has Saved My Work More Than Once

When you run out of RAM, the OS doesn't crash immediately. It takes pages that no one has accessed in a long time, and offloads them somewhere on your disk. That's what swap is, also called a paging file.

Usually swap is stored on a disk — either an HDD or SSD. It's slower than RAM, but it's incomparably better than getting an out of memory error and losing unsaved work (shoutout to everyone who's ever lost half a day's work that way).

What if we don't put the swap on a disk, but in VRAM instead?

Video memory is, of course, not DDR4. However, on sequential operations, it's noticeably faster than even a decent NVMe. Very roughly, by order of magnitude:

The numbers here are rough estimates - taken from datasheets and my own old benchmarks, so consider them as "plus or minus" rather than a honest benchmark. Even so, it turns out that VRAM swap could be 5-10 times faster than disk swap. For background Chrome tabs that hang and wake up every half hour, this is more than enough.

How this could be assembled

Here's where things get interesting. The OS doesn't know anything about VRAM - it works with block devices: disks, flash drives, partitions. So, we need to somehow pretend that a piece of video memory is a block device.

One of the elegant options is NBD. It's a protocol where a userspace program catches "read block" and "write block" commands and does whatever it wants inside. Linux supports NBD out of the box, and there's an analogue for Windows - WNBD.

The picture looks something like this:

Browser, Figma, VS Code...
        ↕ (memory pages)
    OS kernel
    (swap / paging file)
        ↕ (block operations)
   NBD / WNBD driver
        ↕ (TCP loopback)
 Our hypothetical server
   (reads/writes to VRAM via OpenCL)
        ↕ (PCIe)
          GPU

OpenCL is a cross-platform API to GPU: it allows allocating buffers directly in video memory and reading-writing to them from the host. It works on NVIDIA, AMD, and Intel.

TCP loopback may seem like an overhead at first - but for requests of 4 KB and above, it almost dissolves against the background of the actual transfer over PCIe. A reasonable trade-off for simplicity of implementation.

Rakes to watch out for in advance

If someone decides to actually assemble this, there are several non-obvious things to watch out for.

VRAM is volatile, and in a very unpleasant way. Regular RAM loses data only when the power is completely pulled out. VRAM, on the other hand, can reset when the driver resets (the so-called TDR — the driver decided that the GPU hung and restarted it), when a monitor is connected or disconnected, or when the system goes to sleep. For swap, this is generally tolerable — it's volatile anyway, and the OS will re-read the data from disk. But it's essential to keep a regular disk swap as a backup; otherwise, a single failure could lead to a kernel panic.

Deadlock under high memory pressure. This is the most insidious issue. The swap server is a process. When memory is scarce, the kernel may want to swap out its own pages. But where to swap them out to? To the swap. Which is handled by this very process. The circle is closed, and the system hangs. This is treated with mlockall() at the beginning of the work: all process pages are pinned to RAM, and the kernel no longer touches them. Without this, everything will come to a standstill under load.

A GPU that simultaneously renders and stores swap. If the card is busy with heavy graphics, OpenCL commands queue up, the swap hangs, and so do the applications. The idea works noticeably better on a second, discrete GPU that doesn't display anything. On a laptop with one card, this is a risk that needs to be taken consciously.

Windows and pagefile on a "removable" disk. By default, Windows doesn't allow setting a paging file on disks it considers removable. WNBD creates fixed disks, so there's usually no problem — but it's better to check in advance rather than being surprised later.

Hibernate doesn't play well with this scheme. When hibernating, Windows dumps the contents of RAM into the pagefile. If the pagefile lives in VRAM, which is erased when turned off, the contents will go nowhere. So it's either hibernate or using VRAM-pagefile as the primary option. Not both.

What this would give me personally

Me, my 8 GB, and Chrome with thirty tabs. Some are active, some are "I'll get back to it later," and some I already can't remember why I opened.

If it were possible to allocate 4–6 GB of VRAM for swap with high priority, long-inactive tabs would be swapped out there — quickly and unnoticed. And when revisited, they would be restored from video memory (at a speed roughly comparable to a fast NVMe) instead of being reloaded from the network or painfully retrieved from disk.

Right now, switching between tasks when there's not enough memory means waiting 10–30 seconds. With VRAM swap, estimates put that at seconds or even fractions of a second. It's a difference you don't see on benchmark graphs, but feel directly with your own hands.

What you can already get your hands on

This, by the way, isn't pure fantasy — some of it was thought up before me.

vramfs (2014) is a FUSE file system built on top of an OpenCL buffer. The project has been abandoned for a long time, it won't run on newer systems without some tinkering, but the core concept works.

GpuRamDrive is a ready-made app for Windows: it creates a virtual disk in GPU memory via CUDA and the ImDisk driver. It only supports NVIDIA, but there's no need to compile anything, and you can set the pagefile on it using standard system tools.

NBD + WNBD + OpenCL is a DIY build put together from open-source components. It works on both Linux and Windows, with any OpenCL-compatible graphics card. But you'll have to grab a compiler and figure out how to set it up yourself.

Who this is for, and who it isn't

Honestly, this is a pretty niche idea.

It makes sense if your RAM is soldered and can't be expanded, or if all your RAM slots are already occupied; if you have a discrete GPU that sits idle in your use case; and if you don't want to deal with OOM crashes, but constantly hitting the disk every five seconds isn't an option either.

It doesn't make sense if your GPU is already busy handling graphics or ML workloads; if you can just buy an extra RAM stick (seriously, just do that if you can); or if you need production-grade reliability — this setup isn't robust enough for that.

And finally...

I haven't built this myself yet. What draws me to this idea is that it centers on a resource that just sits completely unused in certain scenarios. You've got 6 gigabytes on your graphics card while you're tinkering in a text editor, and Chrome over in the corner is choking your system — you have to admit that's a little frustrating.

If anyone has already tinkered with GpuRamDrive or vramfs — let me know how it performs in practice. And I'm separately curious: how does this kind of setup hold up under real-world, tab-heavy workloads, not synthetic benchmarks? Right now I only have theory and frustration from the task manager.