Could anybody please explain to me why there is a need for a special treatment of VRAM compared to a regular system RAM in this use case? Assuming, we can perform an allocation in VRAM (probably using OpenCL API), why can't we use tmpfs/ramfs code? Do I understand correctly that PCI maps VRAM to a certain memory region and it is accessible via regular CPU instructions? Is it because CPU caching is different or VRAM i…
Your graphics drivers aren't written to be able to share resources with tmpfs. Going through OpenCL ensures that the graphics drivers know about and will respect any VRAM allocations.
Ideally then one should be able to use spare VRAM as a second level RAM - an area to page out things to before disk. I've played a bit with the different memory compression tools on Linux, zram, zswap, and zcache, and they all behave in interesting ways on workloads whose active set is well over 2x available RAM. I played with compiling the Glasgow Haskell Compiler on small and extra small instances of cloud services…
> Ideally then one should be able to use spare VRAM as a second level RAM - an area to page out things to before disk. It's already possible on Linux. You can use SWAP file instead of partition and there also SWAP priorities available.
I've found that putting swap files on things that don't behave like filesystems can cause interesting behaviors. In this case, all writes to the file would go through the VFS. I imagine there could be some curious issues if that write path has any allocations or significant amount of mutation in it.
I would trust more something that got rid of the VFS layer and simply allowed VRAM to be used directly as a second level below RAM using the transcendental memory model.
> Ideally then one should be able to use spare VRAM as a second level RAM - an area to page out things to before disk. It's already possible on Linux. You can use SWAP file instead of partition and there also SWAP priorities available.
I've found that putting swap files on things that don't behave like filesystems can cause interesting behaviors. In this case, all writes to the file would go through the VFS. I imagine there could be some curious issues if that write path has any allocations or significant amount of mutation in it. I would trust more something that got rid of the VFS layer and simply allowed VRAM to be used directly as a second leve…
And even some otherwise fairly ordinary filesystems don't support swap files (e.g. btrfs).
Yes, it's owned by the GPU, but you can map it to the regular space. In fact, this is exactly how textures and other data gets loaded to the video card. See http://en.wikipedia.org/wiki/Memory-mapped_I/O
True -- you can use (in OpenCL) clEnqueueMapBuffer to get something that looks like memory-mapped IO, but the consistency guarantees are different from regular host-based MMIO. Specifically, if you map a GPU buffer for writes, there's no guarantee on what you'll get when you read that buffer until you unmap the region. (You can think of it as buffering up writes in host memory until you unmap the region, at which poi…
In other words, OpenCL supports this very limited buffer interface due to compatibility issues, i.e. this kind of MMIO is the lowest common denominator that has to be implemented by any GPU claiming OpenCL compatibility. Although, this does not preclude most desktop discrete GPUs from mapping their whole internal VRAM onto host's memory address space through PCI bus. It seems to be the common mechanism for a host to access VRAM in the modern ATI and NVidia GPUs from what I understood after skimming through several technical documents. It is, by the way, as far as I can tell, the main reason behind the infamous 'memory hole' in 32-bit Windows OS's (inability to use more than 2.5-3G of RAM).
So, I guess, the correct answer to my initial question as to why it's not possible to use tmpfs with VRAM would be because that will require special memory allocation made in VRAM. Meaning, a patch to tmpfs code that can properly allocate memory in VRAM buffer would suffice if we are willing to limit compatibility to 64-bit x86 architecture with AMD/NVidia GPUs.
It's a cool idea; as other posters have mentioned, there have been other projects mapping VRAM for swap, etc. I'd personally be wary of putting anything too important into VRAM. About five years ago I did a bunch of work testing consumer GPU memory for reliability [1, 2]. Because until that time GPUs were primarily used for error-tolerant applications (graphics) storing only short-lived data (textures) in memory, the…
While memory errors in textures would usually cause only visual artifacts (unless used for data), memory errors in executable code, shader programs, vertex data, and other types of data could easily cause more fatal problems.
This is interesting. However, considering how 4GB to 8GB RAM is getting so common nowadays, using a ramdisk e.g. a tmpfs partition is quite useful. I've set Firefox and Google Chrome to use a 1 GB tmpfs partition for their cache and the performance improvement is clearly visible.
This is interesting. However, considering how 4GB to 8GB RAM is getting so common nowadays, using a ramdisk e.g. a tmpfs partition is quite useful. I've set Firefox and Google Chrome to use a 1 GB tmpfs partition for their cache and the performance improvement is clearly visible.
Why use a disk cache on a ramdisk instead of using the memory cache of the browsers? Is it to survive browser restarts?