Unifix knowledge database - The original one

Dashboard - News - Search - List - About - Admin


Alternativ brug al grafikram. (Linux)

Author:skidrow - Sat Jan 29 17:32:25 2005

Et lękkert hack jeg fandt.
Har bibeholdt den oprindelige hackers navn i teksten, for at give ham den credit jeg mener han fortjener.

-------------------
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

Copyright(c) Unifix.org 2002-2011


Dashboard - News - Search - List - About - Admin
 
Powered by Mikjaer Consulting Solutions - Hosted by Specialhosting.dk