| Next: Wireless | Previous: Setup | Contents |
Initially I tried to install SuSE 7.2 with XFree86-4.0.3, but problems with the wireless card led me to obtain and install SuSE 7.3 with XFree86-4.1.0. The generic kernel of SuSE 7.2 uses a 800x600x8bpp VESA framebuffer with a very fancy boot logo. SuSE 7.3 is similar except the resolution is user selectable and the decoration is different. In normal installation of SuSE, in the step of X setup, SaX2 was not able to get the ATI Radeon module of XFree86 4.1.0 to start; later investigation indicated that the Radeon was recognized as such, but of an unknown chip type. I fell back to the VESA framebuffer module (fbdev). Since the video resolution can't be changed after boot, this means 800x600x8 only during installation.
In my lilo.conf file is a cross-reference of video modes. vga=0x31b gives 1280x1024x24. Do not use "video=vesa:ypan"; at least with the versions tried, it displayed random noise on scrolled areas of the screen.
I then re-ran sax2, but it failed to detect any device. Following a suggestion on the SuSE web site, I ran it as "sax2 -m 0=vesa". It didn't want vesa, but did detect fbdev as a useable device. However it wanted to use 16bpp (which wouldn't have worked because of the 24bpp video mode), and when I forced 24bpp, the server wouldn't start. Following lessons from a previous use of fbdev, in section "Screen" I commented out DefaultDepth and Modes. One or the other of these makes it work.
For resolutions less than 1400x1050, the graphics processor can either leave wide margins around a small image, or interpolate onto the full screen, selected by Fn-F7. But on an interpolated dithered image there's a pronounced moiré effect. Examples of dithered images are my favorite "leaves.bmp" background, and the default herringbone background when the server starts up. Of course there is no VESA mode for 1400x1050.
So what is the video mode number for 1400x1050? Various values were found on the web. Trying some, and with a little experimentation of my own, I discovered that 1400x1050x16 is 0x142 (as the poster said) and 1400x1050x24 is 0x143. (That's vga=0x343; remember to add 0x200.)
The ModeLine produced by SaX2 was:
In this mode, a 1024x1024 square is 209x209 mm, i.e. square pixels. This is 49 px/cm or 124 px/inch. (Probably it's really 50 px/cm or 127 px/inch.) The display size is 286x214 mm. Lacking an explicit DisplaySize, the server assumes that the resolution is 75 px/inch, leading to bizarre scalable fonts. If you specify the DisplaySize explicitly in the Monitor section (as shown in the sample XF86Config), the resolution will be reported correctly, and scalable fonts selected by point size will appear realistically and independent of the screen resolution. Credit for this point to Stefan Jaschke http://www.jaschke-net.de/Dell-Inspiron-4100.htmlModeLine "1400x1050" 147.04 1400 1432 1600 1768 1050 1054 1058 1074 -HSync -VSync
With this version of the framebuffer driver, when you suspend to RAM and
then resume, there is a small amount of garbage on the screen, which clears
over a 7 second interval, after which control returns to the user. Changing
VTs works fine. Over a suspend, or over VT flips using gpm, the mouse remains
operational. The only problem seen was that when you terminate your xsession
and the xdm login box is put up, the mouse is inoperative. If you then flip
VTs and flip back, the mouse is restored.
Radeon Driver
So I have the framebuffer working properly. The Radeon module is the next challenge. I downloaded XFree86-4.1.99.4 (from the CVS server of xfree86.org), which has a patch so it is recognized. This driver was successful but there were problems doing DRI (q.v.) Later, XFree86-4.2.0 was released and I downloaded that. Here are some pointers for compiling XFree86.
The Radeon module (from both 4.1.99.4 and 4.2.0) works well.
When you suspend to RAM, and then resume, the display comes up totally trashed
and sits there for about 7 seconds, then instantaneously clears.
Flipping VTs works fine. In both cases, the mouse remains operational.
Everything works out if you terminate your xsession, then log in again,
including the mouse. (With both the framebuffer and the Radeon module,
there's a tendency to spurious mouse clicks on resume, so it's best to
leave the cursor in the background.)
Direct Rendering Infrastructure (DRI)
What is DRI? DRI is the XFree86 equivalent of Microsoft's DirectX. It enables a user space program to map video RAM (using a special device) and change pixels without going through the X-server, which obviously is much faster. XFree86 combines the Mesa 3D rendering library and the OpenGL library (an open source version of Silicon Graphics' GL graphics library), with pixel delivery via DRI. There are other GL variants. Specifically, xf86_glx uses a Mesa implementation executing as a module of the X-server to do ``indirect'' 3D rendering, whereby the client passes high-level 3D information to the X-server, which uses the glx module to render it. For more information see the DRI Users Guide, or the project's home on Sourceforge.
Despite much struggle, DRI under XFree86-4.1.99.4 was not working. Once I downloaded and compiled XFree86-4.2.0 (and given setup steps accomplished under the previous version), DRI worked right away. However, several important infrastructure items need to be addressed first.
AGPGART. This device is an address register or DMA channel which enables the AGP-capable video chip to access main memory that may be fragmented in multiple blocks. It has its own kernel module and device, and the module needs to be patched or you will get a kernel ``oops''. The patches are:
If your distro does not have the AGPGART device inode premade, do``mknod /dev/agpgart c 10 175''. With devfs it's in /dev/misc/agpgart and you may need to make a compatibility symlink.
It is possible to include this Option in the Device section of your XF86Config file, to select 4X AGP, which the chipset is capable of:
Option "AGPMode" "4"
Radeon Kernel Module. This module is not built by default; in your XFree86 sources you need to cd to xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ and execute ``make -f Makefile.linux radeon.o''. Then copy radeon.o (or the driver for whatever other card you might have) to /lib/modules/$vers/kernel/drivers/char/drm/radeon.o (where $vers represents your kernel version or related symlink). Also edit /etc/modules.conf adding the lines:
alias char-major-226 radeon pre-install radeon /sbin/modprobe "-k" "agpgart"
Permissions. The user on the console needs permission to read and write on /dev/dri/card0. There are various ways to bring this about, but a very tempting choice is to add it to /etc/logindevperm (and using PAM logins in xdm with pam_devperm.so). I did that (I'm using devfs) and something went very wrong, crashing the system. I traced it down to specifically the chown and reported it as a bug. Likely it would be safe without devfs, but if you do use devfs, then until the bug is fixed, either specify your own loginID in the DRI section of XF86Config, and mode 600, or no user (default is root) and mode 666. I believe the AGPGART is only used by the X-server, so doesn't need its permissions changed.
3Ddiag. This program checks if your 3D software is configured correctly. /usr/bin/3Ddiag --dri fails to recognize the graphics chip. Do "lspci"; find it on 01:00.0. Repeat "lspci -n" and discover its PCI ID which is 1002:4c59 (in hex). Edit /usr/bin/3Ddiag.dri and insert this code in the section before the Radeon driver selection. (Search for the word ``radeon''.) With this fixed, it is looking for an xf86_glx setup, which is not what's installed, and the following complaints are seen:
These are the symbolic links referred to by 3Ddiag. To keep the table readable I've abbreviated thus:
| $UL | /usr/lib |
| $UXL | /usr/X11R6/lib |
| $UXLE | /usr/X11R6/lib/modules/extensions |
| From | Xfree86-4.2.0 | Mesasoft | switch2xf86_glx |
|---|---|---|---|
| $UXLE/libGLcore.a | file | missing | libGLcore.a.xf86_glx |
| $UXLE/libglx.a | file | missing | libglx.a.xf86_glx |
| $UL/libGL.so.1 | $UXL/libGL.so.1 | GL/libGL.so.1.2.mesasoft | GL/libGL.so.1.2.xf86_glx |
| $UL/libGLcore.so.1 | (removed in all variants) | ||
| $UXLE/libglx.so | (must exist) | ||
| $UL/libMesaGL.so.3 | libGL.so.1 (all variants) | ||
| $UL/libglide3.so.3 | glide/libglide3.so.3.voodoo* (only those cards) | ||
To protect my XFree86-4.2.0 libraries if switch2something else were ever executed, I renamed the items labelled ``file'' above, and made symbolic links in the xf86_glx style. I also copied switch2xf86_glx, calling it ``switch2native'', and modified (and simplified) it to recreate the native mode symbolic links.
Configuration Tips. I got this checklist (and other pointers) from the Sourceforge DRI site:
Speed Tests. With all of this set up, direct rendering works. I downloaded and ran Mesa-4.0.1 with the demos, getting these results. The program ``glxgears'', which comes with XFree86-4.2.0, is almost the same as ``gears'' in this demo set and gives about the same frame rates. A unit of f/s means frames per second; px/s means pixels per second; it/s means iterations per second. ``Soft'' means Mesa libraries as compiled (distro's Mesasoft gives different, slightly slower rates), ``indirect'' means using xf86_glx off the distro, which refuses to use direct rendering and uses indirect rendering instead, and ``direct'' means using XFree86-4.2.0. On all tests where help and fog were present, these were turned off (giving a faster frame rate). Two of the demos rely on features that are not implemented in the Radeon hardware, driver or libGL plugin, so they had to be skipped under DRI.
| Test | Soft | Indirect | Direct | Description |
|---|---|---|---|---|
| bounce | fast | fast | faster | Bouncing ball, like ico. |
| clearspd | 7.11e8 px/s | 6.46e8 px/s | 7.72e8 px/s | Clearing window to solid color |
| cubemap | sedate | missing ext | Rotating cube mapped to circle | |
| drawpix | 5.57e8 px/s | 1.58e7 px/s | 1.21e7 px/s | Drawing a static image |
| fire | 0.928 f/s | 0.560 f/s | 68.9 f/s | Spewing blue lava |
| gears | 241 f/s | 230 f/s | 605 f/s | Rotating gears |
| geartrain | 18.5 f/s | 19.2 f/s | 74.2 f/s | Different rotating gears |
| gloss | 14.2 f/s | 13.7 f/s | 155 f/s | Raytracing specular reflections |
| gltestperf | 2826 it/s | 1556 it/s | Non-obvious generic test | |
| glutfx | fast | fast | fast | Mouse controls object's orientation |
| ipers | 1.25 f/s | 0.75 | 13.4 | Rotating fractal object |
| morph3d | fast | fast | faster | Morphing platonic solids |
| multiarb | sedate | fast | Not sure what it's doing | |
| pixeltex | fast | fast | Speeds up using pixel texture generation. | |
| pointblast | fast | Looks funny | Balls scatter and bounce. | |
| ray | 16.7 f/s | 8.47 f/s | 64.3 f/s | Raytrace on a spherical mirror |
| readpix | 7.70e7 px/s | 3.28e6 px/s | 6.13e5 px/s | Reading pixels? |
| reflect | 75.2 f/s | 73.4 f/s | 79.6 f/s | Raytrace in flat mirror |
| renormal | fast | faster | Not sure what it's doing. | |
| shadowtex | fast | missing ext | Lighting and shadow casting | |
| teapot | 3.4 f/s | 2.04 f/s | 65.2 f/s | Shadowed 3D teapot |
| terrain | 28.9 f/s | 15.5 f/s | 153 f/s | Random terrain overfly (fog off) |
| texcyl | 239 f/s | 209 f/s | 976 f/s | Rotating textured cylinder |
| texdown | 2.98e3 ?/s | 39.2 mb/s | 89.7 mb/s | Not sure what it did. |
| texobj | fast | faster | Rotating flat panels | |
| trispd | 1.46e7 px/s | 9.70e6 px/s | 1.00e8 px/s | Lots of little triangles? |
| tunnel | 2.48 f/s | 1.23 f/s | 118 f/s | Motion through tunnel (fog off) |
| tunnel2 | 4.79 f/s | 2.28 | 124 f/s | In tunnel, 2 windows (fog off) |
Only the dynamic tests are shown above. The following are static tests. All of them work.
| gamma | Color test pattern |
| isosurf | Irregular 3D surface. |
| lodbias | Image smearing. |
| occlude | Whether object is visible. |
| paltex | Color gradient and overlay. |
| spectex | Lighting varies in direction |
| stex3d | Textured 3D image |
| tessdemo | Breaks polygon into triangles. |
| texenv | Various operations on images |
| winpos | N copies of an image |
There is a range of speedup, mostly from 5x to 100x, depending on exactly what the demo is doing. I also compared DRI with 4X AGP vs 1X. gears, ray and texdown speeded up 3%, trispd speeded 8%, but most tests showed no change. (See above for a warning on system freezing.)
It has been noted on the net that with DRI engaged, some 2D operations are slower. Notice above the poor performance of drawpix and readpix. For some chipsets the effect is radical, but on the Radeon, major slowdowns are confined to a few operations which don't seem to occur that often in ``real life''. Here are the results of the xbench test suite. The test procedure of xbench is to send as many action requests to the server as it will swallow in the nominal test duration, and then to do a X-sync and pixel readback, to make the server flush all the operations. When that finishes the test is over. But on large filled rectangles the server chokes ungracefully on the overload, crashing the machine. Thus the test was run with a sync after each individual operation. This distorts the results, but not radically.
| Test | -sync | No DRI | With DRI | Unit |
|---|---|---|---|---|
| line500 | y | 57600 | 77952 | vectors/sec |
| line500 | n | 57600 | 51968 | vectors/sec |
| fillrects500 | y | 8.32e8 | 6.88e8 | Pixels/sec |
| fillrects500 | n | not tested | crashes | |
| tiledrects400 | y | 7.58e8 | 4.10e8 | Pixels/sec |
| arcs500 | y | 14880 | 13564 | arc/sec |
| filledarcs500 | y | 6664 | 7702 | arc/sec |
| screencopy500 | y | 4.20e8 | 9.05e7 | Pixels/sec |
| imagestring:9x15 | y | 2.89e6 | 4.44e5 | chars/sec |
| complex1 | y | 2233 | 2126 | runs/sec |
| complex1 | n | 2330 | 2125 | runs/sec |
So the screen copy and imagestring tests in xbench are significantly slowed, but the others are within a factor of 2, some faster with DRI and some slower. Using xgc, most of the tests finish in 0.000 seconds, making comparison difficult, but in many of the remaining tests, the DRI version is faster. Consistent with the mesademo results, the worst slowdown occurred for putimage, which was 50 to 100 times slower depending on the plane mask. Plotting individual dots (points) also was 5 times slower with DRI, only for the plane mask with all bits on (the faster variant). And text output was slower but it's hard to tell how much due to small numbers. These were the only tests in xgc for which DRI was slower.
| Next: Wireless | Previous: Setup | Contents |