Whole document tree
6. Various Topics
6.1. Memory Type Register Ranges
Starting with Pentium class processors and including Athlon, K6-2 and other CPUs, there are Memory Type Register Ranges (MTRR) which control how the processor accesses ranges of memory locations. Basically, it turns many smaller separate writes to the video card into a single write (a burst). This increases efficiency in writing to the video card and can speed up your graphics by 250% or more.
See /usr/src/linux/Documentation/mtrr.txt for details. Note that since this file was written, XFree86 has been patched to automatically detect your video RAM base address and size and set up the MTRRs.
6.2. Milking performance from your system for all it's worth
If for some reason you're using X 3.3, follow the instructions given by mtrr.txt (see section 5.1) to set up your MTRRs. X 4.0 does this automatically for you.
Don't run a window manager (wm). Some wm's like twm don't take up much CPU cycles, but still rob you of performance. Some window managers like enlightenment will definitely produce a noticeable slow down. To run a game without a wm, you modify .xinitrc in your home directory. Here is what my .xinitrc looks like:
#quake3 +set r_gldriver libGR.so.1 #/usr/local/games/SinDemo/Sin #exec ut #lsdldoom -server 2 #exec tribes2 exec /usr/bin/enlightenmentThis file tells X what client to run upon starting. Usually this is your wm, and/or a desktop manager (GNOME or KDE). Comment out the lines containing a wm and desktop manager with a pound sign (#) and place your game on a new line with any command line arguments you want to pass. If the game is not located in your $PATH, give its full path name. Note that this is for people who use `startx' to start X.
I never use things like gdm or run-level 5 (so I'm not positive here), but I suspect that if you do, you'll need to do things a bit differently. My best guess is to go to single user mode (run-level 1) by:
# telinit 1
then edit .xinitrc, then go back to run-level 5 by
# telinit 5
Then when you stop playing, go to run-level 1, modify .xinitrc then go back to run-level 5. I don't use this stuff, so I'm not sure, but you may need to kill gdm. I'd appreciate some feedback on this.
Kill all not-essential processes. Of course you'll have to do this as root. A better way to do this than typing "ps ax", getting ntpd's pid, and sending it a SIGKILL (with kill -9) is to make use of pidof:
# kill -9 `pidof ntpd`
However, an even better alternative is to use the startup scripts on your system. On Debian, the startup scripts for run-level 2 are located in /etc/rc2.d/. You can kill a service in an orderly manner by sending its startup scrip the `stop' command:
# cd /etc/rc2.d # ./ntpd stopAnother (radical) option is to simply put yourself in single-user mode with
# telinit 1
This will even get rid of getty; your system will be running nothing which is absolutely crucial to its operation. You'll have something like 10 processes running. The downside is that you'll have to play the game as root. But your process table will be a ghost town, and all that extra CPU will go straight to your game.
6.3. About libraries on Linux
A common problem you'll see in gaming is a library file not being found. They're kind of mysterious and have funny names, so we'll go over libraries on Linux for a bit. There are two types of libraries, static and dynamic. When you compile a program, by default, gcc uses dynamic libraries, but you can make gcc use static libraries instead by using the -static switch. Unless you plan on compiling your games from source code, you'll mainly be interested in dynamic libraries.
6.3.1. Dynamic libraries
Dynamic libraries, also called a “shared library”, provide object code for an application while it's running. That is, code gets linked into the executable at run time, as opposed to compile time. They're analagous to the .dll's used by Windows. The program responsible for linking code “on the fly” is called /etc/ld.so, and the dynamic libraries themselves usually end with .so with a version number, like:
/usr/lib/libSDL.so
/lib/libm.so.3
|
When using gcc, you refer to these libraries by shaving off the strings lib, .so and all version numbers. So to use these two libraries, you would pass gcc the -lSDL -lm options. gcc will then `place a memo inside the executable' that says to look at the files /usr/lib/libSDL.so and /lib/libm.so.3 whenever an SDL or math function is used.
6.3.2. Static libraries
In contrast to dynamic libraries which provide code while the application runs, static libraries contain code which gets linked (inserted) into the program while it's being compiled. No code gets inserted at run time; the code is completely self-contained. Static libraries usually end with .a followed by a version number, like:
/usr/lib/libSDL.a
/usr/lib/libm.a
|
The .a files are really an archive of a bunch of .o (object) files archived together, similar to a tar file. You can use the nm to see what functions a static library contains:
% nm /usr/lib/libm.a
...
e_atan2.o:
00000000 T __ieee754_atan2
e_atanh.o:
00000000 T __ieee754_atanh
00000000 r half
00000010 r limit
00000018 r ln2_2
...
|
When using gcc, you refer to these libraries by shaving off the strings “lib”, “.a” and all version numbers. So to use these two libraries, you would pass gcc the -lSDL -lm options. gcc will then `bolt on' code from /usr/lib/SDL.a and /usr/lib/libm.a whenever it sees a math function during the compilation process.
6.3.3. How are library files found
If you compile your own games, your biggest problem with libraries will either be that gcc can't find a static library or perhaps the library doesn't exist on your system. When playing games from binary, your library woes will be either be that ld.so can't find the library or the library doesn't exist on your system. So it makes some sense to talk about how gcc and ld.so go about finding libraries in the first place.
gcc looks for libraries in the ``standard system directories'' plus any directories you specify with the -L option. You can find what these standard system directories are with gcc -print-search-dirs
ld.so looks to a binary hash contained in a file named /etc/ld.so.cache for a list of directories that contain available dynamic libraries. Since it contains binary data, you cannot modify this file directly. However, the file is generated from a text file /etc/ld.so.conf which you can edit. This file contains a list of directories that you want ld.so to search for dynamic libraries. If you want to start putting dynamic libraries in /home/joecool/privatelibs, you'd add this directory to /etc/ld.so.conf. Your change doesn't actually make it into /etc/ld.so.cache until you run ldconfig; once it's run, ld.so will begin to look for libraries in your private directory.
Also, even if you just add extra libraries to your system, you must update ld.so.cache to reflect the presense of the new libraries.