XFree86 4.1.0 and ATI Radeon: The Original
Linux graphic performance is significantly improved by the latest version of XFree86, making Linux viable as a workstation operating system. Major motion picture studios including DreamWorks and Pixar are adopting Linux as their standard movie production workstation. In this article we will install XFree86 4.1.0, and upgrade our version of Linux to Debian Sid and kernel 2.4.7. We will also build and install the open-source accelerated ATI All-In-Wonder Radeon graphics card driver.
XFree86 is a popular implementation of the X Window System, a technology developed in 1984 at MIT as part of Project Athena. MIT's goal was to make their existing assortment of incompatible workstations from various manufacturers into a network of graphical workstations. At first X was used primarily at MIT and DEC where there was also development, but in 1986 it was commercially released. Eventually MIT handed X off to the X Consortium, later folded into Open Group. In 1999 Open Group spun off X.org. X.org estimates that more than 30 million people are using X, and that number is growing rapidly thanks to Linux and XFree86.
X had stagnated for a decade. In 1992 the project that became XFree86 was founded, with the goal of offering a free implementation of X. The significant new features of X--font anti-aliasing, compositing and DRI--are due to XFree86. A volunteer organization, anyone may join XFree86 and gain direct access to the Xfree86 code and docs in CVS. Originally focused on Intel x86, XFree86 today has the goal of being the best windowing system on every platform available. It runs with Linux, the BSDs, Mac OS X, Solaris and OS/2. CPUs supported include x86, Alpha, PowerPC and Sparc, with MIPS in development.
In March of 2000 a redesigned XFree86 was released. Version 4.0 added much better graphics acceleration, plus features such as X-Video and multihead support with Xinerama. X-Video provides support for color space alternatives to RGB, such as YUV used in television and movies. Animators, in particular, often need to work with more than one monitor at a time. Ordinary multihead configuration supports placing windows on multiple monitors. Xinerama enables one window to span multiple physical screens simultaneously.
XFree86 3-D graphics performance is significantly improved by the addition of direct rendering infrastructure (DRI) and GLX. OpenGL is a platform-independent scene description language well suited for animation, and closely tied to hardware. GLX is the window-event code that connects the driver-level OpenGL graphics language with the X Window System. GLX and OpenGL were both developed by SGI.
DRI is a pipeline that bypasses inefficiencies in the X server to directly bind the kernel, X server, OpenGL and graphics drivers together. All modern high-performance graphics boards now offer accelerated drivers for Linux, with the notable exception of 3D Labs, who have a driver in development.
A particularly handy feature when configuring XFree86, VESA Display Data Channel (DDC) enables XFree86 to query modern monitors for their supported screen resolutions and refresh rates. XFree86 4.x integrates the read-edid utility to determine the correct monitor mode-line settings automatically.
In June of 2001 XFree86 4.1.0 was released. Besides bug fixes, this version has many more supported drivers; of particular interest to us is the ATI Radeon. All the Radeon cards have excellent graphics performance, but the All-In-Wonder version of Radeon has the added feature of a built-in TV tuner. ATI, who had a bad reputation with open-source developers, went from being the worst to one of the best, and sponsored the development of the Radeon open-source driver.
Daryll Strauss built the first accelerated Linux 3-D driver (for 3dfx hardware) in his spare time while working at Digital Domain on the renderfarm for Titanic. That was the first major film to have its effects rendered primarily using Linux. (See "Linux Helps Bring Titanic to Life" by Daryll Strauss and Wook in the February 1998 of Linux Journal.) Strauss went from working on Titanic at Digital Domain to building Linux graphics drivers as lead for multimedia at Precision Insight, now a part of VA Linux. Precision Insight was funded by ATI, Intel, Matrox and 3dfx to build DRI-compatible Linux drivers.
I think that open source is the way to go. In 18 months we built ten drivers: 3dfx Voodoo 3/4/5, ATI Rage 128/128 Pro/Radeon, Matrox G400, Intel i810/i815 and another not yet announced. Creating a common code base really helped. In looking at the source and documentation of proprietary drivers under NDA we discovered that the vendors' code and hardware share many features.
His group did a limited implementation for Radeon, without acceleration for 3-D transform and lighting. "The thing that's annoying about the Radeon is we created a rasterization driver, effectively turning Radeon into a fast Rage 128," says Strauss. "As soon as you run Maya you notice you don't have the 3-D performance." Maya, reviewed in the October issue, is a popular 3-D modeling application for motion picture film animators.
Being new, XFree86 version 4.1.0 wasn't available as a Debian package when we installed it. In building it from source we encountered some problems along the way that would sink the typical user. The Radeon driver is new, and the installation documentation for it is currently far from adequate. We'll show you how to get over the rough spots.
Debian is offered in three versions: stable (Potato), testing (Woody) and unstable (Sid). Although not necessary to install 4.1.0, we went whole-hog and upgraded from Potato to Sid. It is simply a synonym for unstable. The Debian apt-get program can make upgrades simple and automatic, especially if you have a broadband network connection to handle the download.
During installation we discovered that you can't make it directly from Potato to Sid, but must upgrade to Woody first. The problem is the Woody version of cp provides the -L option and the Potato cp does not, but Sid expects it at installation. The consequence is that upgrading to the Sid version of libc6 fails. Without a working libc our system was really messed up. We couldn't even use vi, but were relieved to have vim installed, a vi-like editor that doesn't rely on libc.
Here's the sequence we followed to fix the problem:
1. Set /etc/apt/sources.list to point instead to testing, by commenting out unstable2. apt-get update3. apt-get -f install4. apt-get upgrade5. Now that testing is installed, point sources.list to unstable6. apt-get update7. apt-get upgrade
The update command sets the database of available packages based on the package sites listed in sources.list. The upgrade command installs any newer versions of previously installed packages. Using apt-get -f install fixed our broken dependencies.
Another odd installation problem was a template parse error message from Perl preventing upgrading debconf. The trick to getting around that was posted on the Debian user list: apt-get install debconf.
Building XFree86 4.1.0 requires upgrading to a 2.4 kernel. We downloaded the 2.4.7 kernel as source, although we could have installed it using a Debian package. The 2.4 kernel is built in the usual way (make: menuconfig, clean, dep, bzImage, modules and modules_install). However, do not specify in configuration that you want the Radeon driver. This counter-intuitive step is necessary to avoid getting a 4.0.x version driver as included with 2.4.7. Instead, we'll build the Radeon driver from source in 4.1.0. Another tip: turn off module versioning.
The XFree86 4.1.0 source is in three tarballs. First unpack these files using tar -xvf. Then build by executing make world in the xc directory. Don't bother trying to redirect the screen output to a file for study later. There is too much of it, and it takes too long.
We didn't check our disk space first (with df), ran out of disk space in the middle, and had to start over on a partition with more space. While you're at it, you may want to check how much memory you have with cat /proc/meminfo. Note that you don't type make world on the second go unless you want to start over from the beginning, instead type make.
Creating a new partition to make room to work on XFree86 was an adventure of its own. Our hard drive layout was ext2 (primary), swap (extended) and NTFS (primary) partitions. A large drive with a lot of unallocated space, we wanted to carve up the remaining space into several partitions. But, cfdisk would only offer to make one last primary partition. Although there is a limit of four primary partitions, we couldn't figure out why we couldn't make the fourth partition an extended partition and put as many logical partitions in there as we needed. The answer is you are only allowed one extended partition. We had to make the swap partition into a primary partition in order to make the last partition an extended one. Changing that extended partition to primary changed most of our partition numbers (when hda5 became hda2). We had to touch up our fstab mounts file to reflect that:
swapoff -a cfdisk mkswap /dev/hda2 vi /etc/fstab
Next we went through a little dance with Windows 2000, also installed on the drive (and bootable directly from LILO). Win2k wouldn't finish booting because we had changed its partition number. As with fstab in Linux, we needed to increment the partition number in the Windows /boot.ini file. That was a problem. We couldn't boot Win2k, and Linux NTFS access is read-only. We booted Win2k from CD then chose Repair --> Console. This mode offers only the most rudimentary built-in commands. With no editor here we still couldn't fix boot.ini. We tried to copy boot.ini to a floppy so we could edit it on another machine, but received "access denied". You can only copy from a floppy in the Win2k repair console. We rebooted Linux, copied the file, edited it and wrote it to a FAT floppy using mcopy. We then rebooted to the Win2k repair console and copied the file from the floppy. Phew!
Back in Linux, we experienced problems during the XFree86 4.1.0 build process. For no obvious reason we had to delete a bad .o file manually at one point. And we had to install the zlib1g-dev package because make objected that we didn't have libz. In programs/xdm we had to comment out the PAM_LIBRARIES and PAM defines. Not sure why, but since we don't use xdm we didn't care. We used make install rather than executing the Xinstall.sh script, as would be normal when installing from a binary distribution.
To create a config file we used the new XFree86 -configure option. That immediately failed due to unresolved symbols errors. A known but undocumented bug, the solution is to remove the unnecessary file /usr/X11R6/lib/modules/drivers/glide_drv.o. We ran configure again, and it automatically generated an XF86Config.new file. We then edited that settings file so that our mouse protocol was /dev/gpmdata instead of /dev/mouse, and set our mouse protocol to MouseMan instead of auto. Our older monitor couldn't auto-sense because it doesn't have DDC support. We set the configuration manually to that of a typical 15" monitor:
Section "Monitor" HorizSync 31.5-65 VertRefresh 50-100
We wanted 24-bit 1024 x 768 as our screen mode, and specified that by appending a line to the appropriate display subsection:
SubSection "Display" Depth 24 Modes "1024x768"
To test our new config file we used the command XFree86 -xf86config /root/XF86Config.new. That failed with the error that it couldn't find the fonts Speedo or Type1. Another inadequately documented obstacle, the new XFree86 needs scalable fonts to be specified for loading in the configuration file. We added the following to the modules section, enabling True Type fonts while we were at it:
Load "freetype" Load "type1" Load "speedo"
It should have worked at this point, but we received error messages from the kernel as it attempted to load the radeon.o module. We had module versioning turned on in the kernel configuration but not the XFree86 make file. This meant the kernel used modules with mangled function names, but XFree86 did not. We could see mangled function names when looking for mtrr (one of the missing module entry points provided in the error message) by typing ksyms -a | grep mtrr_add. We turned off module versioning and rebuilt the kernel. (This feature is of dubious value anyway since you wouldn't normally intend to run multiple versions of the same module anyway.)
With our rebuilt kernel we had a new error message, this time from XFree86. It said we had the wrong version of radeon.o. The problem was that our kernel had built the 4.0 radeon module, but we wanted to run XFree86 4.1.0. We would have to remove the 4.0 module and build a newer one. To do that:
cd xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel make -f Makefile.linux
This creates the card-specific modules in XFree86. To install radeon.o we copied it to /lib/modules/2.4.7/kernel/drivers/misc directory where it won't be clobbered the next time we make any kernel modules. We specified the screen resolution we wanted and copied our config file to /etc/X11/XF86Config, one of the default locations. We executed startx to launch, and voila! A working accelerated Radeon card. Since we installed from source we are presented with the default X window manager, twm.
Installing XFree86 4.1.0 won't seem such a challenge when it becomes widely packaged, but building it from source taught us a lot about how XFree86 is put together. The sheer size of it and the complexity of the build process is more than one expects. Vladimir Dergachev, who regularly helps Radeon users on the XFree86 Xpert list, was indispensable in helping us get it to work. He's one of the volunteers actively working on the Radeon driver.
The new DRI architecture with accelerated drivers (both open- and closed-source versions) make Linux a much more powerful platform for graphics. ATI, HP, NVIDIA, 3D Labs, and others are actively working on closed-source drivers. What's not happening is much further development of open-source drivers such as the Radeon driver described here. Precision Insight has gone on to other projects, and no one is currently funding enhancements to open-source drivers or even to XFree86 itself.
The learning curve for volunteers to write DRI-compatible drivers is steep, especially so because of a lack of documentation. With 4.1.0 the changes have settled down in XFree86. It is time to write good documentation that will enable future programmers to build and enhance accelerated drivers. If anyone would like to help please drop me a line.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide