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.

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.

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.

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

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

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

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?

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

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

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

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

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.