This page is a walk through on obtaining Direct Rendering on a mach64 graphics chipset. If you are looking for the ATI Rage 128, this is not the correct page, however this is the page for the ATI Rage Also, if you only want 2D drivers, install just xf86-video-mach64 and skip this.
The Mach 64 Board
The Mach64 Chip is made by ATI. This page is targeted at the Rage Pro video card (not the Rage 128) which to my knowledge is the only 3D version of the mach64. Wikipedia: Mach64/Rage Pro This board has basic 3D capabilites, but Arch's xf86-video-mach64 package does not provide the complete solution. The kernel DRM module is needed, but not included in the kernel. Why Isn't the Mach64 DRM Included In the Kernel?
Most GNU/Linux 3D graphics drivers use the DRI/DRM system for direct rendering, which is what the Mach64 Driver uses.
Packages and References
- mesa - installs the mesa GL libs - Install this with pacman.
- libgl - installs the gl libs (part of the 'official' mesa source tree) (). - install this with pacman
- libdrm - installs the drm libs - install this with pacman
- xf86-video-mach64 - installs the xorg driver
- mach64-dri - installs the dri files for mach64
- DRM - the kernel module that controls DMA, AGP memory management, resource locking, and secure hardware access.
- DRI - Direct Rendering Infrastructure - The X Server Driver. This allows the X server to communicate with the Graphics Card, translating OpenGL into instructions for the video card.
Building the Kernel Drm Module - with makepkg goodness
Before you start: Security Hole Warning Since kernel 2.6.27, The in tree DRM is no longer compatible with the mach64 drm. The kernel must be compiled as follows:
Device Drivers ---> Graphics Support ---> < > Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) ---> (CONFIG_DRM=n) Must be disabled.
If you are using the standard Arch kernel, you must either recompile the kernel or obtain the AUR package "kernel26-nodrm."
After your kernel is properly configured, install the AUR package "mach64drm," which will install the kernel modules compiled from out of tree DRI sources.
Installing the other end: DRI
The new Xorg (1.5.3) brought with it a new driver structure, which included a separate package for the mach64, giving users a mach64 package without having to recompile like with previous Xorg servers. (previously, xf86-video-ati had to be modified to compile mach64 when it was built).
This has made the process of installing DRI much easier, entailing:
pacman -S xf86-video-mach64
This is what my the Device section in my xorg.conf looks like:
Section "Device" Identifier "Card0" Driver "mach64" #most important, allows you to use the mach64 driver Card "ATI Rage Pro - Mach64" Option "DMAMode" "async" #async - default, sync (synchronous DMA), mmio (PIO/MMIO) - Dispatch Buffers. Option "ForcePCIMode" "false" #Boolean, disables AGP aperture. Set to True if you have a PCI card. Option "AgpMode" "2" #(AGP 1x or 2x) valid options: 1 or 2. If not set, defaults to agpgart's mode Option "AgpSize" "32" #Sets the AGP aperture in MB - The video card can access this amount of system memory using AGP and shared access in order to expand its memory capacity - enlarging this allows more textures to be stored here. Option "BufferSize" "2" #Sets DMA buffer memory size in MB. Default is 2 MB. May be 1 or 2. Option "LocalTextures" "true" #By default, AGP cards will only use AGP memory for textures. To force using local card memory for textures in addition to AGP, you may set this option to true. boolean. #The AgpSize option changes the amount of system memory used for the AGP aperture and is not limited by the size of the card's on-board video memory. This memory is used for the DMA buffers (BufferSize option), and the remainder is allocated for AGP textures. Of course, the AgpMode/AgpSize options are ignored for PCI cards or if ForcePCIMode is enabled on an AGP card. However, the BufferSize option can be used to change the size of the DMA buffers in system memory for both PCI and AGP cards (but it's not recommended to reduce the buffer size unless you are short on system RAM). http://www.retinalburn.net/linux/dri_status.html #see "Status and known issues for mach64 branch of DRI EndSection
The Modules Section:
Section "Module" <Your modules> Load "glx" Load "dri" EndSection
The DRI Section:
Section "DRI" Mode 0666 #allows anybody to use DRI EndSection
The DRI Section (For machines where security is a concern):
Section "DRI" Group "video" #Change to any desired group to restrict access Mode 0660 EndSection
After you're in X, you can run the command
glxinfo | egrep "direct rendering|OpenGL renderer"
This should return something like this:
direct rendering: Yes OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE
If OpenGL renderer string says "Software Rasterizer," DRI is not working, even if direct rendering says "yes"
Why Isn't the Mach64 DRM Included In the Kernel?
The official page for the dri/drm driver for mach64 states:
The reason the Mach64 driver isn't built by default yet is due to lack of proper security. At the moment, despite the fact that the client submitted buffers are checked and copied, a malicious client can change the buffer contents after the check/copy because _all_ buffers are mapped on client space. Therefore security can be compromised by using the Mach64 bus mastering abilities to read/write from/to system memory. Things that need to be done: * Provide a mechanism to allocate private DMA buffers which aren't mapped into the clients. The current DRM DMA buffer API is both arcane and incomplete in this this aspect. A new API is being worked, and is useable if these private DMA buffers are allocated by the DRM instead of the DDX. I'm merging into Mach64 branch as I speak, so this point can be considered done. * Allocate and manage the private DMA buffers from above in Mach64 DRM. See http://sourceforge.net/mailarchive/forum.php?thread_id=1925221&forum_id=7177 for a more detailed description of what to do. Besides having to basically write a new/separate buffer management code we also need to integrate it with the existing one. The reason we need to keep the current buffer management code is that plain texture/bitmap data is of no security concern and needs to be dispatched as fast as possible, which means no copying into private buffers. There are more things were the Mach64 driver needs a little work but the items above are the ones preventing it to be merged into the DRI trunk, and upstream. * -- JoseFonseca As an update, the driver is waiting for some changes I'm preparing for the DRM common code that will allow the managament of several DMA buffers pools. I can't really give a timeframe to driver completion - my laptop went dead several months ago and it's no longer something that affects me directly. Still I'm commited to finish it as my time permits it. * -- JoseFonseca
Building the Kernel Drm Module - the Old Way without pacman
warning: this does not use the makepkg method, which is recommended. Please use the AUR packages (top of this document) or create your own. Skip this section if you did the section above, with makepkg.
The standard ARCH kernel doesn't come with the mach64 DRM module, so building yourself is required.
- Create a build folder to keep things tidy - this folder will be referred to from now on as $BUILDDIR
- Now, obtain the drm source tree:
- Get the thing compiled: (the drm folder appeared out of git)
cd $BUILDDIR/drm/linux-core/ make DRM_MODULES="mach64"
- Go get some coffee or something since your machine is probably very old to have a mach64 chipset and wait while everything compiles.
- When it's done compiling, there will be two files,
mach64.ko, the device kernel module, and
drm.ko, the DRM generic module.
- Copy those two files to the appropriate kernel modules directory. (Before doing this you may want to backup the exisiting files to somewhere else just in case).
sudo cp mach64.ko drm.ko /lib/modules/`uname -r`/kernel/drivers/char/drm/
- Now get the modules registered and depedencies generated.
sudo depmod -a `uname -r`