Thursday, February 12, 2004

Understanding My Laptop's Graphics Capabilities

While perusing the FreeBSD-current news archive, I read a thread on comparing glxgears performance. I had never used this tool so I fired it up and saw my Thinkpad a20p laptop's performance:

Xlib: extension "XFree86-DRI" missing on display ":0.0".
303 frames in 5.0 seconds = 60.600 FPS
361 frames in 5.0 seconds = 72.200 FPS
360 frames in 5.0 seconds = 72.000 FPS
360 frames in 5.0 seconds = 72.000 FPS
360 frames in 5.0 seconds = 72.000 FPS

The error message bothered me, and these numbers looked much lower than those in the thread, so I started poking around. I found Eric Anholt's DRI page extremely helpful. I learned DRI is the Direct Rendering Infrastructure, "a framework for allowing direct access to graphics hardware in a safe and efficient manner... The first major use for the DRI is to create fast OpenGL implementations." The DRI page for ATI, the maker of my Rage Mobility 128 card showed it was supported. However, using Eric's troubleshooting page, I failed to see DRM (the Direct Rendering Modules provided DRI) loaded by the kernel. Checking my /var/log/XFree86.log.0 file, I saw attempts to load DRI and DRM:

(II) LoadModule: "dri"
(II) Loading /usr/X11R6/lib/modules/extensions/libdri.a
(II) Module dri: vendor="The XFree86 Project"
compiled for 4.3.0, module version = 1.0.0
ABI class: XFree86 Server Extension, version 0.2
(II) Loading sub module "drm"
(II) LoadModule: "drm"
(II) Loading /usr/X11R6/lib/modules/freebsd/libdrm.a
(II) Module drm: vendor="The XFree86 Project"
compiled for 4.3.0, module version = 1.0.0
ABI class: XFree86 Server Extension, version 0.2
(II) Loading extension XFree86-DRI
(II) LoadModule: "dbe"
(II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a
(II) Module dbe: vendor="The XFree86 Project"
compiled for 4.3.0, module version = 1.0.0
Module class: XFree86 Server Extension
ABI class: XFree86 Server Extension, version 0.2
(II) Loading extension DOUBLE-BUFFER

There were no errors, but I did see this later in the log:

(II) R128(0): Direct rendering disabled

Clearly this was a problem. The first issue I decided to tackle was not seeing drm loaded by the kernel. My laptop runs FreeBSD 5.2 REL. I found a r128.ko kernel module in the /boot/kernel directory, so I tried loading it via kldload:

drm0: port 0x2000-0x20ff mem 0xf0200000-0xf0203
fff,0xf8000000-0xfbffffff irq 11 at device 0.0 on pci1
info: [drm] AGP at 0xf4000000 64MB
info: [drm] Initialized r128 2.5.0 20030725 on minor 0

That's better! I added

r128_load="YES"

to my /boot/loader.conf file to enable this at boot time. Unfortunately, this did not solve my "Direct rendering disabled" problem. Thanks to this thread I added this to my /etc/X11/XF86Config next:

Section "DRI"
Mode 0666
EndSection

This was supposed to ensure that all users could use DRI, but it had no effect on my immediate problem. In the same helpful thread I learned I might be asking too much of my 2000-era graphics card. There might not be enough memory left to run DRI, so I made these changes to the /etc/X11/XF86Config file:

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
DefaultDepth 16
DefaultFbbpp 16
SubSection "Display"
Depth 16
Modes "1400x1050"
EndSubSection
EndSection

By dropping my color depth from 24 to 16, and specifying the frame buffer to be 16, this might give X enough memory to run DRI. Sure enough, it worked!

(II) R128(0): Direct rendering enabled

Trying the glxgears program, I got much better results, and no error messages:

7969 frames in 5.0 seconds = 1593.800 FPS
7977 frames in 5.0 seconds = 1595.400 FPS
6978 frames in 5.0 seconds = 1395.600 FPS
5559 frames in 5.0 seconds = 1111.800 FPS
7393 frames in 5.0 seconds = 1478.600 FPS
7438 frames in 5.0 seconds = 1487.600 FPS

With DRI enabled, I was able to load the Enemy Territory game from the FreeBSD port. At some point I hope to get the TV capabilities of my laptop working using the GATOS drivers and software.

I created a .xserverrc file with these contents to ensure my laptop uses 100 DPI:

exec X :0 -dpi 100

2 comments:

lingwitt said...

Thanks! It is indeed the 16-bit depth.

dghnfgj said...
This comment has been removed by a blog administrator.