8 ms·

Use OpenGL to get more RAM

149 points by devbug 10y ago

Zekio 10y ago
Always need more ram!
kebolio 10y ago
sounds to me like a perverse realisation of amd's apu ideal, treating VRAM like system RAM, although in this case they are still disparate memory spaces.
- mtgx 10y ago
  Isn't VRAM already used as system RAM in the AMD-based PS4?
  - scandinavian 10y ago
    PS4 has 8 GB of unified memory yes. The Xbox 360 had 512 GB of unified memory too.
    - jevinskie 10y ago
      Indeed. You could also use the PS3's VRAM as swap space when using OtherOS (Linux) before Sony removed OtherOS. GPU malware is going to become really interesting once memory-coherent GPUs (like PS4's APU) become more available. That combined with something like packet mmap [1] may allow for data exfiltration from a GPU compute kernel without ongoing userspace assistance (MMIO packet send/recv => no need to have the CPU userspace side dispatch syscalls on behalf of the GPU). [1]: https://www.kernel.org/doc/Documentation/networking/packet_mmap.txt https://www.kernel.org/doc/Documentation/networking/packet_m...
tluyben2 10y ago
It used to be standard to use your VRAM as RAM where possible. If you were not coding a game but something like a business tool, you would just stuff parts of the application in VRAM so you could swap it out from there instead of from HD or, before that, floppy. This was without OS support mostly though. For work I haven't needed this technique since the end of 90s I think.
- astrodust 10y ago
  "Used to be standard" is highly debatable. The only people I ever heard of doing that were the crazy sort, enthusiasts pushing the limits of their rig, not average people.
  - tluyben2 10y ago
    That depends how far back you go. You are talking PC probably; most 'desktop' computers before that had so little memory this was common place and even mostly impossible to do 'useful' business applications without it.
    - astrodust 10y ago
      Citation needed because honestly, I've never heard of this and I think you're confusing it with something else. I've been using computers since the introduction of the original IBM PC and have had to spend a lot of time dealing with memory issues over the years. "Extended memory" drivers were a common thing back then but that was to circumvent the 640KB/1MB limit of DOS and they had nothing to do with video card memory. In that era few people even knew how much memory was on their video card because it was rarely a concern, most of the time it was just barely enough to hold a single frame buffer, typical of most VGA and "Super-VGA" cards. Extended memory is that which is beyond the boundaries of the original IBM PC design: https://en.wikipedia.org/wiki/Extended_memory https://en.wikipedia.org/wiki/Extended_memory It's not video card memory in any way. If I recall correctly the video card memory was often mapped into the 640KB-1024KB memory zone, but using that for system memory was futile since you'd be unable to see anything on screen.
      - tluyben2 10y ago
        I mentioned before PC in my comment to your comment right? You are still going on about PCs; I was not referring to PCs but rather MSX, CPC, Amiga etc. They had distinct RAM & VRAM (in the case of the MSX the cool machines had 128kb-256kb RAM & 128kb VRAM and you could not map one to the other => it was really different memory) and when you used text input screens you were wasting 112kb of memory if you didn't do this. The memory was slower to access from the CPU but it was much much faster than disks. Not confused, just not talking about PCs in general (although I have heard cases of this happening there but that might be just indeed demo groups); I still do this on those old computers today for hobby purposes (the last work I did was somewhere end 90s on a legacy system which counted on video memory and which had to be ported so I had to remove & test that 'feature') ; there just isn't another way to get memory if you don't want to cheat (and solder in 1024kb). Edit: I don't know if it was used in practice because there were so many different VGA cards, but [1] shows that it was common to have 256kb on a card which, depending on the era, was significant. And like said above, for business applications in text based environments (screen 0) you can use a large portion of video memory for storage while you still see something. But I can see the issue there; with other computers we didn't have that issue as you could trust a certain amount to be there for sure. [1] http://www.osdever.net/FreeVGA/vga/vgamem.htm#detect http://www.osdever.net/FreeVGA/vga/vgamem.htm#detect
pjc50 10y ago
Once it's offloaded to the GPU, it could compress it on an LRU basis...
stevetrewick 10y ago
Finally an answer to the age old question "where can I download more RAM?"
- Frenchgeek 10y ago
  http://downloadmoreram.com/ http://downloadmoreram.com/
witty_username 10y ago
This seems useful for AMD APUs where system RAM is reserved by the iGPU.
AshleysBrain 10y ago
Is there a reason operating systems don't/can't do this automatically? It sounds like a faster swap space than disk.
- creshal 10y ago
  This only works when you have a dedicated graphics card (IGPs use system RAM) with dedicated VRAM (some dedicated notebook chips also use system RAM), which is also not needed for anything else (which is what you usually buy a graphics card / GPGPU acceleration card for). That's a so negligible minority of devices (underutilized gaming rigs and nothing else) that OSes just don't bother.
  - AshleysBrain 10y ago
    If you consider that when you're on the desktop and not running a game, all those gigabytes of VRAM are basically going unused. So it should apply to any system with discrete GPU memory, which is surely quite a few systems? I guess those systems correlate with high-end systems with lots of system RAM anyway though...
    - creshal 10y ago
      > So it should apply to any system with discrete GPU memory, which is surely quite a few systems? No smartphones, no tablets, only a small minority of notebooks (not a single macbook, e.g.), none of the business desktop PCs (which are by far the majority, volume-wise), no servers nor workstations (except those that have them installed for GPGPU purposes). The exception are gaming laptops/PCs (and those will need the VRAM for actual gaming) and servers/workstations with dedicated GPGPU cards (which, again, would need the VRAM for GPGPU purposes). That only leaves a few cases where you have beefy hardware and don't use it, which isn't significant enough for OS vendors to bother with. Thirdparty VRAM-as-RAM (or RAM disk) kernel modules / FUSE layers pop up from time to time (this isn't nearly the first), but they never gain any traction. > I guess those systems correlate with high-end systems with lots of system RAM anyway though... Usually VRAM is less than a quarter of the system RAM, or even less. And usually those systems have so much system RAM that they have enough spare to make RAM disks an a valid option.
datenwolf 10y ago
Only, that it doesn't give you any extra memory at all. In case you're using a dedicated GPU, the peripheral bus inbetween (PCIe) is a serious bottleneck. In addition to that the OpenGL object model does not have the concept of automatic "object eviction"; on embedded architectures (Android) you may loose the OpenGL context and have to recreate it. But you'll never loose a single OpenGL object. The bottom line is, that the OpenGL driver will create a backing store in system memory for each and every buffer object. So if you allocate 4GiB of OpenGL buffer objects, it will allocate 4GiB of system memory; if it's a shared memory GPU that's it, if it's a dedicated GPU the GPU RAM is actually more of a cache to the backingstore. glMapBuffer will usually just give you access to this backingstore so that writes can be coalesced into a single transfer when unmapping. Also you don't want a full round trip read-modify-write. In case of coherent mappings the coalesced transfer is triggered by a GPU side data read operation on that buffer. TL;DR: RAM on graphics cards is a cache on top of system memory (as far as OpenGL is concerned).
- graphitemaster 10y ago
  On desktop NV and desktop AMD I've observed (at least on Linux) via /proc/self/maps, that the pointer returned by glMapBuffer is a shared memory mapping owned by libGL. Further inspection shows coalesced reads and writes happening by the kernel through a DMA transfer operation, only when GL_MAP_COHERENT_BIT is used. The mapping is entierly virtual and is not touching physical memory until a R/W occurs. The driver's shared-memory explicitly flushes contents of the read or write request to device memory in the same way CUDA/OpenCL does. This can be observed by the ioctls the driver generates after page-faults occur in the kernel.
snvzz 10y ago
When out of FAST RAM, use CHIP RAM :)
bsorbo 10y ago
While the readme does state this (could be) a joke, this unfortunately isn't possible with PCI-e today: Motherboards only support directly accessing a (up to) 256 MB segment of VRAM directly from the CPU. This is the BAR1 space/aperture space. So attempts to create allocations larger than that that are resident in VRAM but also accessible from the CPU will land in system memory, in order to ensure they are accessible from the CPU. Graphics drivers will either have the GPU read the data from system memory, or will do hidden copies to the GPU when they detect the resource is bound, etc. The author sort of suspects this could be happening: "There is no guarantee that the persistently mapped buffer technique actually references video memory. The worst case it's shadow memory and this actually wastes memory."
- the8472 10y ago
  you could still use vram for paging
- loeg 10y ago
  Why do motherboards have this limitation? There's nothing inherent in PCIe that restricts devices to such a small range. Is this a 32-bit BAR / low 4GB space issue?
  - pmalynin 10y ago
    I'm not sure, BARs can be 64 bit and there is 6 of them.
- StillBored 10y ago
  This sounds like a little bit of confusion. Its the PCIe aperture your referring to, and its size/location is dependent on the machine/bios in use as much as the requested BAR sizes. A lot of recent xeon and workstation level machines actually again support 64-bit PCI aperture windows. See the discussion about which machines are compatible with the xeon phi which requires 8GB (or more) of MMIO space. https://www.pugetsystems.com/labs/articles/Will-your-motherboard-work-with-Intel-Xeon-Phi-490/ https://www.pugetsystems.com/labs/articles/Will-your-motherb... Bottom line, most desktop machines only use a legacy 32-bit PCIe window below 4GB. That is why its limited to a fairly small amount of address space (256-1G generally). The ugly problem is that without purchasing a product its generally quite difficult to determine if it supports a 64-bit aperture correctly. Take the Asus x99A board I have, no mention of support one way or the other, but with an i7 (not just a xeon) it actually works with the xeon phi. (BTW: Nvidia did a better job with this, their tesla cards have a GPU compatibility mode where they restrict the BAR to 256MB for machines that don't support 8GB BARs).
kpgraham 10y ago
I worked with a programmer who cut his teeth on ancient iron in the 1950s. He had a computer that had 4K of ram and two 512 byte I/O buffers. He would set the loader for the program into the I/O buffer and then use that to load and initialize the rest of the program. The I/O buffers would go away on the first read/write. Every byte counted. I used the same techniques when I wrote MASM in the 1990s to create a 16k I/O buffer in the CGA graphics card. The graphics card memory was slower than regular memory, but the 16K made the program fly on reads and writes. I remember a utility that used the Hercules Video card memory for EMS (paged) memory. I think it came with the card.
userbinator 10y ago
A new implementation but not a new concept: https://wiki.archlinux.org/index.php/swap_on_video_ram https://wiki.archlinux.org/index.php/swap_on_video_ram http://ft23.pmenier.net/docext/mtd/TIP_Use_memory_on_video_card_as_swap.html http://ft23.pmenier.net/docext/mtd/TIP_Use_memory_on_video_c... This may be the very first occurrence of the idea on Linux: http://web.archive.org/web/20081227185259/http://hedera.linuxnews.pl/_news/2002/09/03/_long/1445.html http://web.archive.org/web/20081227185259/http://hedera.linu...
- jwilk 10y ago
  Hey, I remember using it back in 2005, when extra 28 MB made a big difference. :-) It was surprising slow, though still faster (and quieter!) than HDD.
deleted 10y ago
[deleted]
philsnow 10y ago
Around 2002 I had bought a machine with a duron cpu, which required a different kind of memory. I still had lots of memory for my old machine, something like 768MB cobbled together out of 64-256MB DIMMs. So I created a ramdisk on the old machine, exposed it as a nbd (network block device), mounted it on over the network (one hop over a 100 Mbit switch, didn't have Gbit kit) on the new machine and created a swapfile on it. I couldn't believe how well it worked. I never actually had any flakiness issues and I used it like that for probably a year.
known 10y ago
IMO Firefox need more CPU than RAM

149 points by devbug 10y ago

Zekio 10y ago

Always need more ram!

sounds to me like a perverse realisation of amd's apu ideal, treating VRAM like system RAM, although in this case they are still disparate memory spaces.

mtgx 10y ago
Isn't VRAM already used as system RAM in the AMD-based PS4?
- scandinavian 10y ago
  PS4 has 8 GB of unified memory yes. The Xbox 360 had 512 GB of unified memory too.
  - jevinskie 10y ago
    Indeed. You could also use the PS3's VRAM as swap space when using OtherOS (Linux) before Sony removed OtherOS. GPU malware is going to become really interesting once memory-coherent GPUs (like PS4's APU) become more available. That combined with something like packet mmap [1] may allow for data exfiltration from a GPU compute kernel without ongoing userspace assistance (MMIO packet send/recv => no need to have the CPU userspace side dispatch syscalls on behalf of the GPU). [1]: https://www.kernel.org/doc/Documentation/networking/packet_mmap.txt https://www.kernel.org/doc/Documentation/networking/packet_m...

tluyben2 10y ago

It used to be standard to use your VRAM as RAM where possible. If you were not coding a game but something like a business tool, you would just stuff parts of the application in VRAM so you could swap it out from there instead of from HD or, before that, floppy. This was without OS support mostly though. For work I haven't needed this technique since the end of 90s I think.

astrodust 10y ago
"Used to be standard" is highly debatable. The only people I ever heard of doing that were the crazy sort, enthusiasts pushing the limits of their rig, not average people.
- tluyben2 10y ago
  That depends how far back you go. You are talking PC probably; most 'desktop' computers before that had so little memory this was common place and even mostly impossible to do 'useful' business applications without it.
  - astrodust 10y ago
    Citation needed because honestly, I've never heard of this and I think you're confusing it with something else. I've been using computers since the introduction of the original IBM PC and have had to spend a lot of time dealing with memory issues over the years. "Extended memory" drivers were a common thing back then but that was to circumvent the 640KB/1MB limit of DOS and they had nothing to do with video card memory. In that era few people even knew how much memory was on their video card because it was rarely a concern, most of the time it was just barely enough to hold a single frame buffer, typical of most VGA and "Super-VGA" cards. Extended memory is that which is beyond the boundaries of the original IBM PC design: https://en.wikipedia.org/wiki/Extended_memory https://en.wikipedia.org/wiki/Extended_memory It's not video card memory in any way. If I recall correctly the video card memory was often mapped into the 640KB-1024KB memory zone, but using that for system memory was futile since you'd be unable to see anything on screen.
    - tluyben2 10y ago
      I mentioned before PC in my comment to your comment right? You are still going on about PCs; I was not referring to PCs but rather MSX, CPC, Amiga etc. They had distinct RAM & VRAM (in the case of the MSX the cool machines had 128kb-256kb RAM & 128kb VRAM and you could not map one to the other => it was really different memory) and when you used text input screens you were wasting 112kb of memory if you didn't do this. The memory was slower to access from the CPU but it was much much faster than disks. Not confused, just not talking about PCs in general (although I have heard cases of this happening there but that might be just indeed demo groups); I still do this on those old computers today for hobby purposes (the last work I did was somewhere end 90s on a legacy system which counted on video memory and which had to be ported so I had to remove & test that 'feature') ; there just isn't another way to get memory if you don't want to cheat (and solder in 1024kb). Edit: I don't know if it was used in practice because there were so many different VGA cards, but [1] shows that it was common to have 256kb on a card which, depending on the era, was significant. And like said above, for business applications in text based environments (screen 0) you can use a large portion of video memory for storage while you still see something. But I can see the issue there; with other computers we didn't have that issue as you could trust a certain amount to be there for sure. [1] http://www.osdever.net/FreeVGA/vga/vgamem.htm#detect http://www.osdever.net/FreeVGA/vga/vgamem.htm#detect

pjc50 10y ago

Once it's offloaded to the GPU, it could compress it on an LRU basis...

stevetrewick 10y ago

Finally an answer to the age old question "where can I download more RAM?"

Frenchgeek 10y ago
http://downloadmoreram.com/ http://downloadmoreram.com/

witty_username 10y ago

This seems useful for AMD APUs where system RAM is reserved by the iGPU.

AshleysBrain 10y ago

Is there a reason operating systems don't/can't do this automatically? It sounds like a faster swap space than disk.

creshal 10y ago
This only works when you have a dedicated graphics card (IGPs use system RAM) with dedicated VRAM (some dedicated notebook chips also use system RAM), which is also not needed for anything else (which is what you usually buy a graphics card / GPGPU acceleration card for). That's a so negligible minority of devices (underutilized gaming rigs and nothing else) that OSes just don't bother.
- AshleysBrain 10y ago
  If you consider that when you're on the desktop and not running a game, all those gigabytes of VRAM are basically going unused. So it should apply to any system with discrete GPU memory, which is surely quite a few systems? I guess those systems correlate with high-end systems with lots of system RAM anyway though...
  - creshal 10y ago
    > So it should apply to any system with discrete GPU memory, which is surely quite a few systems? No smartphones, no tablets, only a small minority of notebooks (not a single macbook, e.g.), none of the business desktop PCs (which are by far the majority, volume-wise), no servers nor workstations (except those that have them installed for GPGPU purposes). The exception are gaming laptops/PCs (and those will need the VRAM for actual gaming) and servers/workstations with dedicated GPGPU cards (which, again, would need the VRAM for GPGPU purposes). That only leaves a few cases where you have beefy hardware and don't use it, which isn't significant enough for OS vendors to bother with. Thirdparty VRAM-as-RAM (or RAM disk) kernel modules / FUSE layers pop up from time to time (this isn't nearly the first), but they never gain any traction. > I guess those systems correlate with high-end systems with lots of system RAM anyway though... Usually VRAM is less than a quarter of the system RAM, or even less. And usually those systems have so much system RAM that they have enough spare to make RAM disks an a valid option.

datenwolf 10y ago

Only, that it doesn't give you any extra memory at all. In case you're using a dedicated GPU, the peripheral bus inbetween (PCIe) is a serious bottleneck. In addition to that the OpenGL object model does not have the concept of automatic "object eviction"; on embedded architectures (Android) you may loose the OpenGL context and have to recreate it. But you'll never loose a single OpenGL object. The bottom line is, that the OpenGL driver will create a backing store in system memory for each and every buffer object. So if you allocate 4GiB of OpenGL buffer objects, it will allocate 4GiB of system memory; if it's a shared memory GPU that's it, if it's a dedicated GPU the GPU RAM is actually more of a cache to the backingstore. glMapBuffer will usually just give you access to this backingstore so that writes can be coalesced into a single transfer when unmapping. Also you don't want a full round trip read-modify-write. In case of coherent mappings the coalesced transfer is triggered by a GPU side data read operation on that buffer. TL;DR: RAM on graphics cards is a cache on top of system memory (as far as OpenGL is concerned).

graphitemaster 10y ago
On desktop NV and desktop AMD I've observed (at least on Linux) via /proc/self/maps, that the pointer returned by glMapBuffer is a shared memory mapping owned by libGL. Further inspection shows coalesced reads and writes happening by the kernel through a DMA transfer operation, only when GL_MAP_COHERENT_BIT is used. The mapping is entierly virtual and is not touching physical memory until a R/W occurs. The driver's shared-memory explicitly flushes contents of the read or write request to device memory in the same way CUDA/OpenCL does. This can be observed by the ioctls the driver generates after page-faults occur in the kernel.

snvzz 10y ago

When out of FAST RAM, use CHIP RAM :)

bsorbo 10y ago

While the readme does state this (could be) a joke, this unfortunately isn't possible with PCI-e today: Motherboards only support directly accessing a (up to) 256 MB segment of VRAM directly from the CPU. This is the BAR1 space/aperture space. So attempts to create allocations larger than that that are resident in VRAM but also accessible from the CPU will land in system memory, in order to ensure they are accessible from the CPU. Graphics drivers will either have the GPU read the data from system memory, or will do hidden copies to the GPU when they detect the resource is bound, etc. The author sort of suspects this could be happening: "There is no guarantee that the persistently mapped buffer technique actually references video memory. The worst case it's shadow memory and this actually wastes memory."

the8472 10y ago
you could still use vram for paging
loeg 10y ago
Why do motherboards have this limitation? There's nothing inherent in PCIe that restricts devices to such a small range. Is this a 32-bit BAR / low 4GB space issue?
- pmalynin 10y ago
  I'm not sure, BARs can be 64 bit and there is 6 of them.
StillBored 10y ago
This sounds like a little bit of confusion. Its the PCIe aperture your referring to, and its size/location is dependent on the machine/bios in use as much as the requested BAR sizes. A lot of recent xeon and workstation level machines actually again support 64-bit PCI aperture windows. See the discussion about which machines are compatible with the xeon phi which requires 8GB (or more) of MMIO space. https://www.pugetsystems.com/labs/articles/Will-your-motherboard-work-with-Intel-Xeon-Phi-490/ https://www.pugetsystems.com/labs/articles/Will-your-motherb... Bottom line, most desktop machines only use a legacy 32-bit PCIe window below 4GB. That is why its limited to a fairly small amount of address space (256-1G generally). The ugly problem is that without purchasing a product its generally quite difficult to determine if it supports a 64-bit aperture correctly. Take the Asus x99A board I have, no mention of support one way or the other, but with an i7 (not just a xeon) it actually works with the xeon phi. (BTW: Nvidia did a better job with this, their tesla cards have a GPU compatibility mode where they restrict the BAR to 256MB for machines that don't support 8GB BARs).

kpgraham 10y ago

I worked with a programmer who cut his teeth on ancient iron in the 1950s. He had a computer that had 4K of ram and two 512 byte I/O buffers. He would set the loader for the program into the I/O buffer and then use that to load and initialize the rest of the program. The I/O buffers would go away on the first read/write. Every byte counted. I used the same techniques when I wrote MASM in the 1990s to create a 16k I/O buffer in the CGA graphics card. The graphics card memory was slower than regular memory, but the 16K made the program fly on reads and writes. I remember a utility that used the Hercules Video card memory for EMS (paged) memory. I think it came with the card.

userbinator 10y ago

A new implementation but not a new concept: https://wiki.archlinux.org/index.php/swap_on_video_ram https://wiki.archlinux.org/index.php/swap_on_video_ram http://ft23.pmenier.net/docext/mtd/TIP_Use_memory_on_video_card_as_swap.html http://ft23.pmenier.net/docext/mtd/TIP_Use_memory_on_video_c... This may be the very first occurrence of the idea on Linux: http://web.archive.org/web/20081227185259/http://hedera.linuxnews.pl/_news/2002/09/03/_long/1445.html http://web.archive.org/web/20081227185259/http://hedera.linu...

jwilk 10y ago
Hey, I remember using it back in 2005, when extra 28 MB made a big difference. :-) It was surprising slow, though still faster (and quieter!) than HDD.

deleted 10y ago

[deleted]

philsnow 10y ago

Around 2002 I had bought a machine with a duron cpu, which required a different kind of memory. I still had lots of memory for my old machine, something like 768MB cobbled together out of 64-256MB DIMMs. So I created a ramdisk on the old machine, exposed it as a nbd (network block device), mounted it on over the network (one hop over a 100 Mbit switch, didn't have Gbit kit) on the new machine and created a swapfile on it. I couldn't believe how well it worked. I never actually had any flakiness issues and I used it like that for probably a year.

known 10y ago

IMO Firefox need more CPU than RAM