сегодня возвращался с работы, попутно почитывая ЛОР с мобилы. и наткнулся на одну замечательную вещь!

оказывается, можно использовать память на видеокартах не только для фреймбуффера и модных игрушек, но и в качестве дискового раздела! в частности, можно приспособить ее под своп!

оригинал статьи: VRAM Storage Device — How to use the memory on GFX board in a different way…

а я, на всякий пожарный, ее зазеркалирую ниже

---

VRAM Storage Device — How to use the memory on GFX board in a different way…

2002-09-03 01:09 by Michał Schulz

 

Have you ever thought why does your graphics card have so much memory? Do You
think you have not enough RAM or awfully slow swap file? Do you need fast
ram-disk or diskless machine? Go for it! Take one of these cheap 32MB graphics
cards and enjoy the speed.

1. Requirements

In order to use VRAM as a storage device you need:

• XFree86,
• MTD compiled as the modules (especially slram),
• Gfx card with tons of memory which we would never use otherwise.

2. Preparation

In order to use the memory you have to find, where Gfx video ram is placed within
PCI address space. It can be done in many different ways. What I did first was
the general check of GFX card resources:

1. execute lspci (or even better lspci -vvv) and look for the entry called similar to
   "VGA compatible controller". There should be at last one such entry which describes
   GFX card and its resources. In my case it looked as follows:

   01:00.0 VGA compatible controller: nVidia Corporation Vanta [NV6] (rev
   15) (prog-if 00 [VGA])
           Flags: bus master, 66Mhz, medium devsel, latency 248, IRQ 10
           Memory at d6000000 (32-bit, non-prefetchable) [size=16M]
           Memory at d4000000 (32-bit, prefetchable) [size=32M]
           Expansion ROM at <unassigned> [disabled] [size=64K]
           Capabilities: [60] Power Management version 1
           Capabilities: [44] AGP version 2.0

   There are two addresses possible. Please note, that this is true for NVidia
   cards only. Others may have more or less address spaces. One of «Memory at»
   entries here says about MMIO address space. The other is gfx ram. This
   information is not enough, so it’s high time to ask XFree86 about some details.

2. XFree86 puts some log information on the screen. They are also recorder in
   /var/log/ in XFree86.log (or sometimes XFree86.0.log and so on). One can find
   all needed information about GFX ram (which is also called here linerar
   framebuffer):

   meehow:~# cat /var/log/XFree86.0.log |grep framebuffer
   (**) NV(0): Depth 24, (--) framebuffer bpp 32
   (--) NV(0): Linear framebuffer at 0xD4000000

   As You may see, in my case GFX ram starts at physical address 0xd4000000. Now
   when one knows how much memory hes card has and where it starts, the experiment
   may be performed!

3. Configuring MTD

MTD is the acronym for Memory Technology Devices (please look at
http://www.linux-mtd.infradead.org/
for more details), allowing us to use Flash
memories, DoC devices and others. Now I’m going to use it in a bit unusual way
(though very simple).

One of mtd drivers handles RAM devices directly accessed through PCI bus. As we
may read:

Many PC chipsets are incapable of correctly caching system memory above 64M or
512M. A driver exists which allows you to use this memory with the linux-mtd
system.

It’s the different issue but fits perfectly now. We do have an additional memory. We
cannot add it for the kernel use (that would require some more sophisticated tricks
and would be not too efficient). But of course we may use is as a block or a char
device. Driver which handles that is called slram. (CONFIG_MTD_SLRAM kernel
option). Besides this we will need mtdcore, mtdblock (if the block access is needed)
and/or mtdchar (if the char access required).

4. Few calculations

XFree86 uses PCI information to know where it should create a displayable image.
That means if we will decrease the video memory size and tell XFree86 that the video
card has less memory than it can detect, the rest will remain unused and
untouched by the X11. It will be possible then to use it ourself.

The quantity of the video memory needed for X11 depends on the video resolutions used.
The easiest is to multiply width by height by bytes_per_pixel of the highest
mode used by XFree86 on the machine. Than some quantity may be added which will
be used by for example XAA extension. Please note, that most common GFX cards
use FOUR bytes per pixel in 24bpp modes. If you use the framebuffer console, you
must take account at it’s resolution as well.

Let’s assume, that we decided to give 4MB of memory for XFree86 (4MB is
0x00400000 in hex). If the video framebuffer starts at 0xd4000000, then the memory
available for MTD will begin at (0xd4000000 + 0x00400000) 0xd4400000. What we
know now is the location and the size of memory for our device.

5. Fixing the XF86Config

In order to tell XFree86 how much memory it should use, you have to fix XFree86 a
bit. Otherwise, X11 will detect memory size and use it all. We don’t want that.
In a Device section you need to add the line:

VideoRam 4096

It will limit the video area to 4MB. If XFree86 has to be
restarted after this fix.

CAUTUION! It WILL NOT work with nVidias binary drivers. They just ignore VideoRam option!
On the other hand it works perfectly with XFree86’s nv driver.

6. Birth of MTD device

Everything is prepared now. We may begin then:

meehow:~# modprobe slram map=VRAM,0xd4400000,+0x00c00000

My graphics card has 16MB memory onboard. I’ve left 4MB for X11 driver. The rest
(12MB = 0x00c00000) is for MTD device. Let’s have a look whether we succeed:

meehow:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00b00000 00010000 "VRAM"

Hooray! The mtd0 device is installed and redy for use. How to work with it?
Quite easy. First of all you must check whether /dev/mtd0 and /dev/mtdblock0
devices are present in the system (it will be of course different on systems
with devfs). If they are not there, they must be created. If the char device is
needed, one has to type:

meehow:~# mknod /dev/mtd0 c 90 0

And be sure that mtdchar module is loaded (or make sure that kernel will load
it when needed). For block device:

meehow:~# mknod /dev/mtdblock0 b 31 0

And the module needed to access it is mtdblock now.

The device is set up. That’s all. Anyone survived?

7. What the hell can I do with that?

Well, many things. When I was thinking about it, I have found two ways to use
it. One of them is making any filesystem on that:

meehow:~# mkfs.ext2 /dev/mtdblock0

and mounting it somewhere, the other is more sophisticated:

meehow:~# mkswap /dev/mtdblock0
Setting up swapspace version 1, size = 12582912 bytes

meehow:~# swapon /dev/mtdblock0

Later on, more possibilities occur. You can use this methon in X11
terminals, to limit network bandwitch for example. During bootup such terminal would load
kernel and compressed filesystem. The FS may be placed then on such mtdblock
device and kernel may boot from it. Using console-only server with some kind of
modern 32MB gfx card may use the vram as huge swap (which is way faster than
swap on disk). New ideas are welcome Contact me at:
michal.schulz(at)tu-clausthal.de