> Built for laptops with soldered memory and no upgrade path. If you have an RTX card sitting there with 8GB of VRAM and you're getting swapped to SSD, this puts that VRAM to work.
Well, that does at least answer my immediate question about why I would ever swap from expensive RAM to really expensive RAM:) Feels niche, but when you want it it's a good idea.
Another possible reason that occurred to me: what if you have VRAM but you're not using it all the time? For example, let's say you bought a GPU because you like to play video games. When you're not actively gaming, you probably don't need 16 GB of VRAM just to render the desktop. Might as well use it for something else, right?
Edit: Although, this is predicated on the system being able to release VRAM that is acting as swap when it's time to start a game. Can it do that?
I am catching up on comments
The reason I wrote this is I run this laptop in hybrid (AMD display + NVIDIA as swap). So all at VRAM was going to waste.
On your question re: switchable swap. It's on my to-do list ;)
Wouldn't this prevent the nvidia GPU from being power gated since it's never "idle"? So like your battery life regresses?
Is VRAM not directly accessible by the system then? Since it's mapped directly into the CPU's address space, I had assumed that there's a simple DMA controller managing said access and I would then also naively assume that said controller is separate (or at least on a separate power plane) from the actual GPU.
While it may prevent sleep, one of the frustrations I have on an old skylake desktop with a bunch of 1080ti GPUs is that when set to power saving modes, the GPUs sit at 1x2.0 pcie lanes and low wattage. That slows down loading quite a bit.
So it will use more power, but nothing close to when the GPU is being used.
It's easy enough to 'offline' swap space on Linux normally so I suspect that would work fine, as long as you didn't instantly run out of RAM when doing so.
If you have enough swap on disk available, it should be fine.
Best case is if gaming and productivity (with high memory use) activities are not concurrent, and productivity applications are stopped before gaming starts, then `swapoff` can easily release swap device without restart.
> you probably don't need 16 GB of VRAM just to render the desktop
Microsoft: hold my beer
So can VRAM actually be used like regular RAM? E.g. if I have a 16GB module and my GPU has 16GB VRAM, could it be made so that my system reports 32GB RAM? What would be the implications of that?
It behaves like slower ram I assume, due to the increased distance from the CPU and overhead. Still, it’s much faster than normal SWAP which uses a disk or SSD.
How it is reported? As SWAP space, not as RAM.
Typical desktop GPU ram does not support being write-back cached by the CPU. With PCIe resizable BAR, you could map the area into ram, so you could technically fit 32GB to memory, but it would have to be uncached (or write-combine cached), which would make it really, really slow.
There are a bunch of datacenter GPUs that support full cache coherency, but if you used them like that the VRAM would be very high latency from the CPU. So it would only be really slow.
I assume on Linux you could use something like daxctl to tell the kernel to treat the vRAM as normal RAM, but I think this would be Intel/AMD only.
I don't think it would help. It's not just a software issue that can be fixed in the kernel, the hardware fundamentally isn't part of the cache coherency system of the CPU.
This is correct, look at IBM's CAPI for an example of the needed hardware
[flagged]
In the olden days we called that a "RAM Disk" and it made our Atari STs go really fast!
On the old Amstrad PCWs that were everywhere at least in the UK in the mid 80s to mid 90s you could have up to 512kB of RAM, a fair chunk of which could be a RAM disk. This made compiling stuff in Turbo Pascal really fast too :-)
Except swap is, like, opposite of RAM disk.
That said, still an nice and fun concept. Though caching got better since I assume :)
RAM disk is, like, the brd module on Linux, which allocates and exposes a /dev/ram0 block device.
From the project description this looks like it, exposing a raw block device backed by VRAM (with some trip through the nbd protocol, but that's an implementation detail to have it in userland, it could just as well have been implemented kernel side).
It's just that the usage of this mem-backed block device is different than the thing of yore (copy HD or floppy into RAM)
The more frequent alternative to brd, tmpfs, skips the block device part and does a filesystem directly. I wonder if it could be made so that it's swap directly and skip the block device part entirely like tmpfs.
[dead]