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.

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).

ForcePCIMode: boolean, disables AGP aperture. Set to True if you have a PCI card.

AgpMode (AGP 1x or 2x): 1 or 2. If not set, defaults to agpgart's mode.

AgpSize: 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.

LocalTextures: boolean, 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.

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).
[1] (dead link)

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

Testing DRI

After you're in X, you can run the command glxinfo | egrep "direct rendering|OpenGL renderer"
This should return something like this:

Why Isn't the Mach64 DRM Included In the Kernel?

"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.

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."

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