HN Reader

That's cool but I think the proper solution is to write a Linux kernel module that can reserve GPU RAM via DRM to create ramdisks, not create a userspace filesystem using OpenCL.

That would give proper caching, direct mmap support if desired, a reliable, correct and concurrent filesystem (as opposed to this author's "all of the FUSE callbacks share a mutex to ensure that only one thread is mutating the file system at a time"), etc.

On the topic of coercing bits into functioning as data storage: harder drive ( http://tom7.org/harder/ )

Somewhat related, there is NVIDIA CUDA Direct Storage[0] which provides an API for efficient “file transfer” between GPU and local filesystem. Always wanted to give it a try but haven’t yet

[0]: https://docs.nvidia.com/gpudirect-storage/index.html

2 GB/s is pretty crappy, that’s about the burst speed of many nvme SSDs.

Virtual disk should me more then 6 gb/s at least with ddr5.

What is the overhead on a FUSE filesystem compared to being implemented in the kernel? Could something like eBPF be used to make a faster FUSE-like filesystem driver?

could be a good place to sequester a swap file, similar to zram

If you want a vramfs, why would you use GPU VRAM? CPU<->GPU copy speeds are not great.

I have 192GB of CPU VRAM in my desktop and that was cheap to obtain. Absolute best build decision ever.

Using something like this would keep the GPU powered on and unable to shut itself off.

These days is it better to use an old video card or a few PCIE NVME multiplexer for those same lanes?

Doesn't the graphics processor of the pi double as bootstrap loader?

using precious vram to store files is a special kind of humor. especially since someone actually implemented it. kudos

Cool, I love that there are ways to utilize RAM and VRAM as filesystems. Sometimes you just don't need all that pure RAM/VRAM.