[_ihaque]

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, there wasn't a whole lot of pressure to make sure the memory was as reliable as that found on the main system board. We found that indeed, there was a persistent, low level of memory errors that could be triggered depending on access pattern. I haven't followed up for recent generations, but the fact that the "professional" GPGPU boards both clock their memory slower and include hardware ECC is possible cause for concern with leaving anything too important on the GPU for a long time.

There's code [3,4], too, but I haven't actively worked on it in a few years, so no guarantees on how well it runs nowadays...

[1] http://cs.stanford.edu/people/ihaque/papers/gpuser.pdf

[2] http://cs.stanford.edu/people/ihaque/talks/gpuser_lacss_oct_...

[3] https://github.com/ihaque/memtestG80

[4] https://github.com/ihaque/memtestCL

[JoshTriplett]

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.