Direct Rendering for older video cards

[Hlingler]

June 25 2010: F11 is now end-of-life, and therefore this project is now closed. As detailed in Post #91, as of F12, the Mach64 DRM kmod source code is no longer present in either X.Org or Kernel trees. My thanks to those who supported this project.

===========================================

Fedora includes 3D video drivers that provide direct (aka "hardware-accelerated") rendering (DRI) for a number of older and off-name (i.e., other than ATI or NVidia) videocards/chipsets. Many can be activated by simply configuring the OS correctly. This HOW-TO is NOT intended to cover those chipsets.

A few of the X.Org DRI 3D video drivers are not included in the current release or are disabled, for various reasons. The ATI Mach64 driver is one, due (apparently) to apathy. However, the source code is available from dri.freedesktop.org git. Since I have spent countless hours and other resources getting the DRI Mach64 3D driver working, I figured that it would be most useful if shared, so that others with the same chipsets/cards could benefit from the drivers, if they so desire. I'll consider adding unreleased 3D drivers for other cards if requested and if possible.

Cards covered by Mach64 DRI 3D driver (http://dri.freedesktop.org/wiki/ATIMach64):

ATI Mach64

Status

DRI support for mach64 has been moved to the DRI and Mesa trunks. This means DRI works on any recent distribution as of 2007.

On Linux systems, the DRM module is not included in official kernels....

All mach64 chips with a triangle setup engine are supported. This includes the 3D Rage Pro, 3D Rage LT Pro, 3D Rage XL, 3D Rage XC, and 3D Rage Mobility. Cards without a triangle setup engine cannot be supported; this includes VT chips, 3D Rage, 3D Rage II/II+/IIc, and 3D Rage LT.

In response to the inevitable question: "Is my card supported?", my answer is: "I have no idea. Check the list."

If you have an older supported SIS (see Post #2) or ATI Mach64-class chipset/card, I have made the various softwares available for download. F8/9/10/F11 and x86 only (F11: SRPMs now available for re-build on other architectures). F12 cannot be supported at this time. Instructions for their use follow. NOTE that F10 uses F9 RPMs. (2009-01-07: F8 support officially ended; 2009-07-10: F9 support officially ended.)

First, the required disclaimers. From the DRI wiki:

Warning: In case you didn't notice, you are about to compile and install experimental software. This will allow you to test the latest features and bug fixes. It may, however, also introduce new bugs. Be prepared for problems every now and then.

And the usual disclaimer: the software is provided in the hope that it will be useful, but comes with no warranty of any kind, including merchantability for any fit purpose. Use solely at your own risk.

This post has reached it's word/character size limit. Please refer to Post #5 below for info on updates.

With that out of the way....

The files are located at: http://www.4shared.com/dir/6321255/3...6/sharing.html. Not GPG-signed.

If at any time you're unsure about how to proceed, or something goes wrong, STOP, and post back here with details.

It will be most useful later on to have a benchmark to measure the graphics performance. Unfortunately, there are no good ones readily available, so glxgears will have to do. Perform this test with no other load on your system. Open a terminal as any user and command: glxgears. You will see a pop-up window appear, with three spinning gears. Do not hide/cover/minimize the gearbox. Let run 30-60 seconds before closing (or kill with CTL-c from the console). The terminal output will list frames-per-second in 5-second increments. Make note of the average for later comparison.

All of the following must be done as full root user.

Next, download and install the new RPM packages:

!!!CAUTION!!! Failure to (properly) install all of the required, matching software may result in a failure of X11/GUI.

• REQUIRED (F11: libdrm and xorg-x11-drv-mach64 are OPTIONAL):

  rpm -Uvh libdrm mesa-dri-drivers mesa-libGL xorg-x11-drv-mach64

• OPTIONAL (if already installed, update):

  rpm -Uvh freeglut mesa-libGLU mesa-libGLw xorg-x11-drv-ati

• OPTIONAL - DEVELOPMENT (if already installed or if needed, install/update):

  rpm -Uvh freeglut-devel libdrm-devel mesa-libGL-devel mesa-libGLU-devel mesa-libGLw-devel

These RPMs will replace your existing packages. If rpm balks for any reason (due to version number confusion), then force the install with --force [--nodeps] option(s).

Then copy the two *.ko kernel modules (drm.ko & mach64.ko or sis.ko) to folder /lib/modules/<uname -r>/kernel/drivers/char/drm/, where <uname -r> is the kernel number corresponding to the *.ko version, overwriting the existing files (if needed). Use the chmod and chown commands (as root-user) to alter file ownerships and permissions to: -rwxr--r-- root:root ...

NOTE: IMPORTANT! Starting with kernel-2.6.27.5-37.fc9, the drm.ko goes in folder /lib/modules/<uname -r>/kernel/drivers/gpu/drm/ and the mach64.ko goes in folder (create folder if needed) /lib/modules/<uname -r>/kernel/drivers/gpu/drm/mach64/.

All kernel modules are specific to one and only one kernel, and will not work for any other kernel(s). The kernel version number has been prepended to these kernel modules for easy identification - strip the number from the filenames so that they read simply: drm.ko and mach64.ko or sis.ko . "Vanilla" kmods will not work for PAE kernels! If you need PAE kmods, post a request and I'll build them.

Inform the kernel that it has some new friends, and have it register their dependencies:

depmod -a

If all has gone well up to this point, you may now load the kernel modules:

modprobe drm
modprobe mach64 [or sis]

The order is important. You should get nothing but a new prompt. You may check with: lsmod|grep drm and/or: lsmod|grep mach64 [sis]. You may view info with: modinfo drm and/or: modinfo mach64 [sis]

A few changes to your xorg.conf before restarting the X-server:
> Back up the existing file /etc/X11/xorg.conf first
> From the DRI wiki:

In order to activate 3D acceleration make sure your xorg.conf is set up right. In particular, make sure the GLX and DRI modules are being loaded:

Section "Module"
# ...
Load "glx"
Load "dri"
# ...
EndSection

and set the permissions for DRI appropriately. To allow anyone to use DRI, do:

Section "DRI"
Mode 0666
EndSection

I found it necessary to add a few more things. Here are the relevant entries in my xorg.conf (EDIT 2008-05-09: removed 'Option "Composite" "Disable" '):

Section "Device"
        Identifier  "Videocard0"
        Driver  "ati" [or: "sis" or: "mach64"]
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
        DefaultDepth     16
        SubSection "Display"
                Viewport   0 0
                Depth     16
                Modes    "832x624" "800x600" "720x400" "640x480" "640x400" "640x350"
        EndSubSection
EndSection

Section "Server Flags"
        Option "AIGLX" "off"  <= F9 "on"
EndSection

Your available "Modes" will be dictated by your VRAM.

NOTE: F11 a few extra tweaks are required to create the special character device node: http://forums.fedoraforum.org/showpo...7&postcount=63

Finally, close all running windows and log out of the desktop. Re-start the X-server with: ALT-CTL-Backspace.

Assuming that you still have a functional graphical interface, log in, and check things out with: glxinfo|grep render. You hope to see: "Yes". If so, run glxgears again to get some idea of how well the new 3D driver is performing. See attached pics.

[vince@etower Thu Apr 03 01:38:10 ~]$ glxinfo|grep render
direct rendering: Yes
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX
[vince@etower Thu Apr 03 01:38:49 ~]$

If all that actually works, it is also highly recommended that you reduce display color depth to 16 bpp for best performance. The 3D DRI may inexplicably fail if you do not have enough VRAM to view the display at a minimal resolution. The resolution setting itself has little effect on performance in this scenario. Finally, don't expect too much out of this driver. Forget Compiz-Fusion, it's not going to happen. You won't get anywhere near the output you might have gotten with the proprietary ATI driver for M$ Win*. For an ATI 3D Rage Pro Turbo AGP 2X on-board chip with 4 MB SGRAM, my glxgears FPS increased from ~75-80 to about 250 FPS max., and that's after reducing color depth to 16 bpp and resolution to 832x624 (which is the max for 4 MB VRAM). For an ATI 3D Rage Pro AGP 2X card with 8 MB SGRAM, I'm able to get 1024x768 @ 16 bpp, with very similar output running glxgears (or 24 bpp but with lower framerates). Not bad for 10-year-old video chips and drivers built from scratch.

Questions/comments/feedback always welcome.

Enjoy,
V

[Hlingler]

2008-07-02: SIS support discontinued effective immediately due to lack of interest. Existing packages and files will remain available indefinitely, but there will be no further updates.

Since they're built and uploaded, and people are downloading them, I guess I've added the SIS DRI drivers....

I find it impossible to accurately determine what SIS cards/chipsets are supported. Here's what the DRI wiki says:

Silicon Integrated Systems (SiS)

Chipsets

Status

A DRI driver for the SiS300 series cards (300/305, 540, 630/730) is currently available in DRI CVS. A DRI driver for the SiS6326 and 530 cards is in development. The newer 315 and Xabre series chips are not supported; neither are the SiS-based Volari chips from XGI (Volari V3XT, V5, and V8).

Here's what the author of the 2D SIS driver says:

DRI:

* DRI ("Direct Rendering Infrastructure") is the basis for OpenGL and hardware 3D acceleration. Without DRI, X.org/XFree86 will use software rendering for OpenGL and 3D which is really slow.
* The X driver this page is about has nothing to do with DRI. Instead, a separate driver is needed for this feature. This separate driver is developed by the DRI developers. I do not do any DRI related development, hence asking me questions about DRI is useless (and such questions won't be answered).
* DRI is only supported on the 300 series (300/305, 630, 730). A DRI driver for the SiS 300 series is provided by XFree86 4.1, 4.2(.1), XFree86 4.4 and X.org 6.7.0 and later. XFree86 4.3 does not contain a SiS DRI driver; However, installing the drivers from 4.2(.1) works well.
* Once again: There is no DRI/OpenGL/3D support for the SiS 6326, 5597/5598, 530/620, 315, 550, 650, 651, 740, 330, 661, 741, 760, 761 including all model variations with letters in the model number.
* About XGI: Although there is a binary XGI DRI driver for the Volari Vx chips available from XGI, this DRI driver is not supported in connection with the X driver available here or in X.org/XFree86. Hence there is no DRI/OpenGL/3D support for the XGI Volari V3XT, V5, V8 chips yet, unless you dare to use XGI's "own" X driver which comes with the said binari DRI driver. (The Volari Z7 has no 3D engine, so thinking about DRI is moot.)
* For a little more information on DRI on the 300 series, see here .

Exactly the opposite of the ATI mach64 situation, the SIS kernel modules are shipped with the kernels - but the 3D driver (sis_dri.so) is not. Go figure.

Follow the above instructions, replacing ALL instances of "mach64" with "sis". The DRM (libdrm and drm.ko) is the same for both.

The SIS stuff is completely untested. I have no SIS cards/chipsets, and so no way of testing the drivers. Feel free to destroy your equipment testing them for me.

Enjoy. Feedback appreciated.

V

EDIT: There is also a configuration utility available that will give you a very minimal GUI to work with:
yum install driconf
Standard Fedora repos. Run driconf as root user the first time to generate default config files. After that, any user can run it to adjust what few settings are available. Note that driconf will fail if used with the proprietary ATI or NVidia drivers installed (because they replace the stock libGL).

[lambcutlet]

Hlingler,
excellent post i have been trying unsuccessfully for ages to get 'direct rendering' functional. I have a Compaq Armada M700 which required the 'mach64' driver, running f8 with xfce. I only ever found 1 liveCD (I think it was knoppix) that managed to get 'direct rendering' functional.
for your info i have gone from 130fps to 300fps. Still not fast enough for 'extreme tux racer' but an improvement none the less.
Questions
Modprobe.conf, to automatically load 'drm' and 'mach64', What did you type? i have tried various things but i always get a warning during the boot sequence. Could you post your modprobe.conf?
Kernel, the latest kernel is ' 2.6.24.4-64.fc8' Do you plan to supply regular updates following the kernel releases by fedora? I for one would be grateful.
Xorg.conf, where do you find information relating to the options? How do you know which ones to turn on and off?

thanks very much you have made 1 fedora user happy

[Hlingler]

Hlingler,
excellent post i have been trying unsuccessfully for ages to get 'direct rendering' functional. I have a Compaq Armada M700 which required the 'mach64' driver, running f8 with xfce. I only ever found 1 liveCD (I think it was knoppix) that managed to get 'direct rendering' functional.
for your info i have gone from 130fps to 300fps. Still not fast enough for 'extreme tux racer' but an improvement none the less.

Glad to hear that. Thanx.

Questions
Modprobe.conf, to automatically load 'drm' and 'mach64', What did you type? i have tried various things but i always get a warning during the boot sequence. Could you post your modprobe.conf?

Hm. After I upgraded to XFCE4-F8, I apparently forgot to put the modprobe commands anywhere! I can't find them...but the drivers still clearly load and work. /var/log/Xorg.0.log is clean and clear as it describes the drivers probing and loading. Perhaps HAL/kudzu have improved.... If yours don't load automatically without being told to do so, try putting the same commands into /etc/modprobe.conf as you would from the CLI (order is important: drm first):

modprobe drm
modprobe mach64

If all that still doesn't work, move those modprobe command lines to /etc/rc.d/rc.local instead.

Kernel, the latest kernel is ' 2.6.24.4-64.fc8' Do you plan to supply regular updates following the kernel releases by fedora? I for one would be grateful.

Yes, I do. I need them, too! Cannot update kmods to 2.6.24.4-64 until I get new nvidia kmods for the machine I build on. Just checked this AM, but still not there. May be a few more days yet....

Xorg.conf, where do you find information relating to the options? How do you know which ones to turn on and off?

Partly from the DRI wiki as stated above, partly from the glxinfo barfing out error messages in verbose mode ("Direct Rendering: No. If you want to find out why, try LIBGL_DEBUG=verbose."). So:

export LIBGL_DEBUG=verbose
glxinfo
<observe cryptic techno-mumble and attempt to translate into useful debugging info>

thanks very much you have made 1 fedora user happy

My pleasure. I'm thrilled that someone else could use this stuff and it actually works.

Regards,
Vince

[Hlingler]

Rather than making a new post every time a new kernel necessitates DRI kernel module updates, I'll just edit this post to announce updated kernel modules from now on.

Since DRI development is ongoing and constant, I may from time to time update the DRM (libdrm), 2D drivers (xorg-x11-drv-*), 3D drivers (mesa-dri-drivers), and mesa shared libraries (mesa-libGL*, freeglut), as seems appropriate and time permits. If so, I'll announce here.

If you can't find a hyperlink to an item you need, feel free to rummage through the main folder: http://www.4shared.com/account/dir/6...6/sharing.html

NOTE: The kernel ID number has been prepended to all kmods for easy identification. Strip those ID numbers from the file names when installing the kmods.

NOTE: In order to avoid failure of updated/new kernel modules to load, perform the depmod before re-booting. Example: suppose I'm running kernel-2.6.24.3-50.fc8.i386 but have installed the updated kernel-2.6.24.4-64.fc8.i386 and the new kernel modules. Before re-booting, as root user, command:

[root@localhost ~]# depmod -a 2.6.24.4-64.fc8.i686

NOTE: IMPORTANT! Starting with kernel-2.6.27.5-37.fc9, the drm.ko goes in folder /lib/modules/<uname -r>/kernel/drivers/gpu/drm/ and the mach64.ko goes in folder (create if needed) /lib/modules/<uname -r>/kernel/drivers/gpu/drm/mach64/.

All software has been tested and works for me unless otherwise noted.

============

2010-02-15: F11: kmods for kernels 2.6.30.10-105.2.23.fc11.i586 (2.6.30.10-105.2.23.fc11.i586-drm.ko, 2.6.30.10-105.2.23.fc11.i586-mach64.ko), 2.6.30.10-105.2.4.fc11.i586, 2.6.30.10-105.fc11.i586, 2.6.30.9-102.fc11.i586, 2.6.30.9-99.fc11.i586, 2.6.30.9-96.fc11.i586, 2.6.30.9-90.fc11.i586, 2.6.30.8-64.fc11.i586, 2.6.30.5-43.fc11.i586, 2.6.29.6-217.2.16.fc11.i586, 2.6.29.6-217.2.8.fc11.i586, 2.6.29.6-217.2.7.fc11.i586, 2.6.29.6-217.2.3.fc11.i586, 2.6.29.6-213.fc11.i586, 2.6.29.5-191.fc11.i586, 2.6.29.4-167.fc11.i586
mesa-libGL-7.6-0.1.1.fc11.ajr.i586.rpm
mesa-dri-drivers-7.6-0.1.1.fc11.ajr.i586.rpm

2009-11-18: F10: kmods kernel-2.6.27.38-170.2.113.fc10.i686 (2.6.27.38-170.2.113.fc10.i686-drm.ko, 2.6.27.38-170.2.113.fc10.i686-mach64.ko), 2.6.27.25-170.2.72.fc10.i686, 2.6.27.24-170.2.68.fc10.i686, 2.6.27.21-170.2.56.fc10.i686, 2.6.27.19-170.2.35.fc10.i686, 2.6.27.15-170.2.24.fc10.i686, 2.6.27.12-170.2.5.fc10.i686, 2.6.27.9-159.fc10.i686, 2.6.27.7-134.fc10.i686.

2009-07-10: F9 support officially ended.

2009-07-07: F9: kmods kernel-2.6.27.25-78.2.56.fc9.i686, 2.6.27.24-78.2.53.fc9.i686, 2.6.27.23-78.2.50.fc9.i686, 2.6.27.21-78.2.41.fc9.i686, 2.6.27.19-78.2.30.fc9.i686, 2.6.27.15-78.2.23.fc9.i686, 2.6.27.12-78.2.8.fc9.i686, 2.6.27.9-73.fc9.i686, 2.6.27.7-53.fc9.i686, 2.6.27.5-41.fc9.i686.

2009-01-07: F8 support officially ended.

============

2008-12-19: F10: Support added; Use F9 RPMs.

2008-11-19: F9: New kernel series 2.6.27: in addition to the new kmods, the following package updates are mandatory:
libdrm-2.4.1-1.fc9.micron.i386.rpm
mesa-dri-drivers-7.2-1.fc9.i386
mesa-libGL-7.2-1.fc9.micron.i386.rpm
mesa-libGLU-7.2-1.fc9.micron.i386.rpm (if installed)
xorg-x11-drv-ati-6.9.0-25.git20080717.fc9.i386.rpm (optional - OK to use Fedora RPM if higher REV.)
xorg-x11-drv-mach64-6.8.0-2.git20080624.fc9.i386.rpm
2.6.27.5-37.fc9.i686-drm.ko
2.6.27.5-37.fc9.i686-mach64.ko

You may safely continue to use previous versions of all other packages. See also note above on new kmod locations.

============

2008-10-26: F8 & F9: Added kmods kernels 2.6.26.6-49.fc8.i686 and 2.6.26.6-79.fc9.i686.

Since it is painfully obvious that Fedora Project will not support Mach64 in F10, I will.

2008-10-02: F9 Add kmods kernel-2.6.26.5-45.fc9.i686; F8 kmods kernel-2.6.26.5-28.fc8.i686.

2008-09-13: F9 Add kmods kernel-2.6.26.3-29.fc9.i686.

2008-09-12: F8 Add kmods kernel-2.6.26.3-14.fc8.i686.

2008-08-17: F8 Add kmods kernel-2.6.25.14-69.fc8.i686.

2008-08-14: F9 Add kmods kernel-2.6.25.14-108.fc9.i686.

2008-07-25: kmods for F8 & F9 kernel-2.6.25.11-60.fc8.i686 & kernel-2.6.25.11-97.fc9.i686.

2008-07-18: F9: Added kmods kernel-2.6.25.10-86.fc9.i686.

2008-07-16: F8: Added kmods kernel-2.6.25.10-47.fc8.i686.

2008-07-03: F8: Added kmods for kernel-2.6.25.9-40.fc8.i686.

2008-07-02: F9: Kmods added kernel-2.6.25.9-76.fc9.i686.
SIS support is discontinued effective immediately due to lack of interest.

2008-06-27: F8: Kmods added kernel-2.6.25.6-27.fc8.i686.

2008-06-15: F9: Added RPMs for mesa-libGLU, mesa-libGLw and freeglut.

2008-06-14: A bug request has been filed to have the mach64 stuff added to Fedora releases: https://bugzilla.redhat.com/show_bug.cgi?id=448346
Please feel free to pile on comments. Seriously: indulge yourself.

2008-06-13: F9: Add kmods kernel-2.6.25.6-55.fc9.i686.

2008-06-13: F9: Updated packages & fix mistakes in first set: libdrm, mesa-libGL, xorg-x11-drv-ati, xorg-x11-drv-mach64

2008-06-12: F9 Added xorg-x11-drv-sis SIS driver & kmods kernel-2.6.25.4-30.fc9.i686.

2008-06-11:
I was able to boot kernel-2.6.25.4-10.fc8.i686 & test the new stuff, and all works good (except I can't test the SIS driver). Again, if you ever need to fall back and boot an older kernel, the older kmods should work with the new drivers and mesa-libGL libraries.

2008-06-10:
IMPORTANT: For F8, starting with kernel series 2.6.25 (kernel-2.6.25.4-10.fc8.i686), DRI code has progressed to a point where updates to the core libraries & packages are required (i.e., the kmods will no longer compile without these updates). If you have previously used the packages & files provided here, you will need to update all of those packages & files anew to work with kernels/modules >= 2.6.25.4-10.fc8.i686. However, older kmods will also continue to work with these other updates (at least, kmods for 2.6.24.7-92.fc8 work with the new packages).

Files and packages now available:
libdrm-2.4.0pre-git20080609.fc8.i386
mesa-libGL-7.1rc1-84git20080609.fc8.i386
xorg-x11-drv-ati-6.8.0-235git20080609.fc8.i386 Note that X.Org have split out the mach64 driver:
xorg-x11-drv-mach64-6.8.0-2git20080609.fc8.i386 Install the new xorg-x11-drv-ati as well!
xorg-x11-drv-sis
2.6.25.4-10.fc8.i686-drm.ko[-mach64.ko,-sis.ko]

Due to failure of kernel-2.6.25.4-10.fc8.i686 to boot on my machines, I was unable to test anything. Feedback encouraged and appreciated.

2008-06-04:
Drivers & kmods for F9 now available - F9 x86 & ATI-Mach64 only at the moment, currently only kmods for kernel-2.6.25.3-18.fc9.i686 are built. Small change in format: rather than goof around with all the run-time libraries separately, I just built the critical mesa-libGL* run-time libraries as RPM packages - should make installing a little quicker and easier, but may require that force be used (only if required):
rpm -Uvh --force --nodeps ...
If anyone needs extra Mesa OpenGL* run-time libraries or stuff (e.g., mesa-libGL*, freeglut, etc.), I'll make them available. ALL are REQUIRED:
libdrm
mesa-libGL
xorg-x11-drv-ati
xorg-x11-drv-mach64
drm.ko
mach64.ko

These ATI-Mach64 drivers and stuff have been tested and work OK on my machines - with minor glitches: I must have screwed up the build a little, so driconf, glxinfo, and glxgears won't work right unless you make a simple sym-link:
ln -s /usr/lib/dri/mach64_dri.so /usr/local/lib/dri/mach64_dri.so
Will fix next build.

2008-05-17:
Kmods kernel-2.6.24.7-92.fc8.i386.

2008-05-09:
It is not necessary to disable 'Option "Composite" ' - in fact, compositing will work with mach64 driver (even at 16 bpp color depth!). See new screenshots in Post #1: desktop compositing (shadows, transparency, etc.) working on F8.i386-XFCE4-LiveCD install.

2008-05-04:
Kmods kernel-2.6.24.5-85.fc8.i386 done & uploaded.

2008-05-03:
Fedora Project has released a new version of xorg-x11-drv-ati (xorg-x11-drv-ati-6.8.0-4.fc8) to the stable updates repo that supersedes my version. You may safely update to this newer version of the package, since it contains no changes that directly affect the mach64 driver. However, you must have AIGLX off as per the example above, or loading will fail. Due to the rapid development of other ATI DRI drivers, the source code changes frequently, and I'll try to limit updates to the various packages/files here to those directly related to or affecting the mach64 driver.

2008-04-04:
kernel-2.6.24.4-64.fc8.i386 kmods available. The sis.ko remains untested.

============

Enjoy. Feedback welcome and appreciated.
V

[lambcutlet]

Hlingler
the new kernel modules '2.6.24.4-64.fc8' work for me as well
and you were correct, you do not need to modify 'modprobe.conf' the modules automatically load themselves
i still can't believe direct rendering is working, superb

[Hlingler]

Hi lambcutlet:

Hlingler
the new kernel modules '2.6.24.4-64.fc8' work for me as well
and you were correct, you do not need to modify 'modprobe.conf' the modules automatically load themselves
i still can't believe direct rendering is working, superb

Outstanding. Time will tell more, but so far all of the mach64 software seems to be stable and working consistently with multiple hardware. Which leads me to a few questions....

Since you are the only "guinea pig" so far, could we get some more info on your setup, for posterity? You mentioned that your machine is a Compaq Armada M700, but a 2-minute tour of their web site turned up little useful info for me. Specifically, what exact chipset/card does it have (I think an on-board "Rage Mobility" of some sort?), and what type of AGP (1X, 2X, 4X, 8X)? How much SGRAM? And on the software side, what color depth and screen resolution are you running? Knowing that will help when comparing performance. Ordinarily, I'd be the first to point out that glxgears is a bad benchmark tool, but it's readily available and common across all installs. If you have time, perhaps you could install package 'hardinfo' from the standard Fedora repos and do the "FBENCH" test, but the results will be useful really only to you, since it compares similar hardware via an on-line database.

I have communicated with only one other individual who has used these drivers (http://sourceforge.net/mailarchive/m....ukl.yahoo.com), and the results appear to be fairly consistent: approx. +150-200% increase in graphics speed over the 2D-only driver, after dropping to 16 bpp. But as you said, that is greater than zero. And maybe the folks at DRI will improve that even more as they continue work.

The hard work is done for me, and it will be trivial to produce new kmods from now on. But after all that work, I would really like to see these drivers get some use, before the old hardware is all scrapped or ends up in museums, and only a few developers care and can use them.

Regards,
V

[lambcutlet]

Hlingler,
My laptop is Compaq Armada M700 PIII 850MHz fitted with 512MB ram and a nonstandard 40GB HD

The graphics is a rage mobility 2x with 8MB running at 1024 x 768 (max setting of display) with 16bit colour (read somewhere in gentoo forums that dri did not work in 24bit).

If you are interested,
attached is a dump of 'dmesg' and hardinfo minus all of the languages, couldn't find FBENCH (is it a seperate install?)

[Hlingler]

The graphics is a rage mobility 2x with 8MB running at 1024 x 768 (max setting of display) with 16bit colour (read somewhere in gentoo forums that dri did not work in 24bit).

Thanx for the info. Virtually identical to my micron.pc before I switched to a better card (http://www.fedoraforum.org/gallery/s...cutoffdate=all). Actually, you can set color depth to 24 bpp if you want, but this will either lower your available resolutions (unlikely) or reduce your graphics speed by (surprise!) exactly half.

If you are interested,
attached is a dump of 'dmesg' and hardinfo minus all of the languages, couldn't find FBENCH (is it a seperate install?)

Yes, beauty to my eyes:

[drm] Initialized drm 1.1.0 20060810
[drm] Initialized mach64 2.0.0 20060718 on minor 0
agpgart: Found an AGP 1.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 2x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 2x mode
[drm] descriptor ring: cpu addr e4cd0000, bus addr: 0x50000000
[drm] DMA test succeeded, using asynchronous DMA mode

The "FBENCH" is the last one, "FPU Raytracing" (lower is better):

FPU Raytracing
--------------

-FPU Raytracing-
<i>This Machine</i> : 63.489
Intel(R) Celeron(R) M processor 1.50GHz : 40.8816714
PowerPC 740/750 (280.00MHz) : 161.312647

Not bad, very comparable to similar hardware. I attached mine for the micron.pc.

I've finally gotten around to looking into possible xorg.conf options that might help performance, but haven't found anything so far.

Regards,
V

[lambcutlet]

Hlingler
I changed to 24bit resolution tested glxgears and got 180fps, if you wish I could perform 'hardinfo' for the results.
I have since returned to 16bits

here is a screenshot of my desktop
http://www.fedoraforum.org/gallery/showimage.php?i=4261

[Hlingler]

Hi lambcutlet:

That's a mighty fine looking picture, if I do say so myself. I may be biased, but I think that the 3D driver gives a much better display quality than the 2D driver alone, all other things being equal. There's nothing wrong with switching to 24 bpp for a session, if you plan on not playing any games nor even flash animations, but for anything that needs graphics speed, 16 bpp is much better and I personally find the lower color depth perfectly acceptable.

I think that you will find the results of hardinfo to be much the same - it's really only useful for tech junkies.

I'm still playing around with other settings to see if anything helps, but haven't found anything, and documentation simply does not exist....

Enjoy,
V

[lambcutlet]

Hlingler
just upgraded my old laptop to F9, previously upgraded my main pc and F9 was faster so i thought what the hell and did the laptop.
Anyway followed your install script to enable direct rendering (2.6.25.4-30.fc9.i686). Using glxgears the fps has gone from 120 to about 180, previously on F8 i was getting 300.
Even the 120fps to 180fps makes a huge difference to the usability of the system. Moving windows about the screen is snappier.
I am getting an error though with libGL, see both attachments.

Then copy libGL.so.1.2, libGLU.so.1.3.070100, libglut.so.3.7.1, and libGLw.so.1.0.0 to folder /usr/lib/, overwriting the existing files (if necessary). <all F9 and F8-2.6.25+ not required, skip this step Remove the sym-link /usr/lib/libGLU.so.1 which points to the older libGLU.so.1.3.070002, and replace it with: <all F9 and F8-2.6.25+ skip this Code: ln -s /usr/lib/libGLU.so.1.3.070100 /usr/lib/libGLU.so.1

i did perform this section above. Could this be my problem?
how do i correct the situation?

keep up the good work

Edit/update
trying to recover my situation by installing the mesa-libGL file. by reinstalling the original file from the fedora repository it restores the libGL.so.1.2, but when i then go ahead and try your mesa-libGL i get this

[root@laptop Download]# rpm -Uvh --force --nodeps mesa-libGL-7.1.rc1-git20080530.fc9.micron.i386.rpm Preparing...                ########################################### [100%]    1:mesa-libGL             ########################################### [100%] error: unpacking of archive failed on file /usr/lib/libGL.so.1.2;48519bd4: cpio: MD5 sum mismatch

is the file not compatible?

[Hlingler]

Hlingler
just upgraded my old laptop to F9, previously upgraded my main pc and F9 was faster so i thought what the hell and did the laptop.
Anyway followed your install script to enable direct rendering (2.6.25.4-30.fc9.i686). Using glxgears the fps has gone from 120 to about 180, previously on F8 i was getting 300.
Even the 120fps to 180fps makes a huge difference to the usability of the system. Moving windows about the screen is snappier.
I am getting an error though with libGL, see both attachments.

Then copy libGL.so.1.2, libGLU.so.1.3.070100, libglut.so.3.7.1, and libGLw.so.1.0.0 to folder /usr/lib/, overwriting the existing files (if necessary). <all F9 and F8-2.6.25+ not required, skip this step Remove the sym-link /usr/lib/libGLU.so.1 which points to the older libGLU.so.1.3.070002, and replace it with: <all F9 and F8-2.6.25+ skip this

ln -s /usr/lib/libGLU.so.1.3.070100 /usr/lib/libGLU.so.1

i did perform this section above. Could this be my problem?

Um... Yes. Those files are all F8 files, and out-of-date also. Remove any that you added/reverse the changes. For the record: only libGL.so.* is absolutely required, you do not need those other extra libs (libGLU*, libGLw*, libglut*) unless you also have packages mesa-libGLU, mesa-libGLw, and/or freeglut installed. If you do have any of those installed, let me know and I'll upload those packages also. I tried to make this a little simpler/easier by just putting the required libGL.so* and DRI drivers into one RPM package (mesa-libGL) like Fedora Project does, but I guess I goofed it up:

how do i correct the situation?
[...]
trying to recover my situation by installing the mesa-libGL file. by reinstalling the original file from the fedora repository it restores the libGL.so.1.2, but when i then go ahead and try your mesa-libGL i get this

[root@laptop Download]# rpm -Uvh --force --nodeps mesa-libGL-7.1.rc1-git20080530.fc9.micron.i386.rpm Preparing...                ########################################### [100%]    1:mesa-libGL             ########################################### [100%] error: unpacking of archive failed on file /usr/lib/libGL.so.1.2;48519bd4: cpio: MD5 sum mismatch

is the file not compatible?

Well, poo. That was the right thing to do, and should have fixed the above problem, but I appears that I screwed up the mesa-libGL package a lot worse than I thought (or maybe a bad upload?). Fortunately, I just re-built it - try this one instead: http://www.4shared.com/file/51172616...icroni386.html If that doesn't fix, it, we'll try some other tricks....

Thanx for the feedback,
V

EDIT: Actually, the output of your second attachment file indicates that DRI is enabled and working - but not well. This stuff is a little more forgiving than I thought. Hopefully, that revised mesa-libGL package fixes it all. You may also notice somewhat lower performance in F9 - I did - nothing to be done about that, it's the new F9 X11/Xorg (which should get better).

[jondawson]

I updated kernel to 2.6.25.4-30, installed the latest rpms, copied the kernel modules into /lib/modules/2.6.25.4-30.fc9.i686/kernel/drivers/char/drm/ for mach64.ko and drm.ko but i get an error message from glxinfo

[jd@vaio ~]$ glxinfo
name of display: :0.0
Error: couldn't find RGB GLX visual or fbconfig

Likewise, glxgears, gives

[jd@vaio ~]$ glxgears
Error: couldn't get an RGB, Double-buffered visual

Am I doing something wrong?

I briefly had the old version working on the old kernel and it gave approx 300fps from glxgears vs 200fps for the indirect fedora drivers for 16bit colour. I noted that Option "AccelMethod" "EXA" in xorg.conf caused the x server to crash in that version.

[Hlingler]

I updated kernel to 2.6.25.4-30, installed the latest rpms, copied the kernel modules into /lib/modules/2.6.25.4-30.fc9.i686/kernel/drivers/char/drm/ for mach64.ko and drm.ko but i get an error message from glxinfo

[jd@vaio ~]$ glxinfo
name of display: :0.0
Error: couldn't find RGB GLX visual or fbconfig

Likewise, glxgears, gives

[jd@vaio ~]$ glxgears
Error: couldn't get an RGB, Double-buffered visual

Am I doing something wrong?

I briefly had the old version working on the old kernel and it gave approx 300fps from glxgears vs 200fps for the indirect fedora drivers for 16bit colour. I noted that Option "AccelMethod" "EXA" in xorg.conf caused the x server to crash in that version.

Hi jon:

Did you remember to run (as root user):
depmod -a 2.6.25.4-30.fc9.i686

Also, check:
ldd /usr/bin/glxinfo

See if it's finding all the right libraries to run:

[Vince@localhost Fri Jun 13 20:13:31 ~]$ ldd /usr/bin/glxinfo
        linux-gate.so.1 =>  (0x00110000)
        libGL.so.1 => /usr/lib/nvidia/libGL.so.1 (0x0602e000)
        libGLU.so.1 => /usr/lib/libGLU.so.1 (0x0662c000)
        libc.so.6 => /lib/libc.so.6 (0x005da000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x007c6000)
        libGLcore.so.1 => /usr/lib/nvidia/libGLcore.so.1 (0x05458000)
        libnvidia-tls.so.1 => /usr/lib/nvidia/tls/libnvidia-tls.so.1 (0x005d6000)
        libm.so.6 => /lib/libm.so.6 (0x00735000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x008c4000)
        libdl.so.2 => /lib/libdl.so.2 (0x00760000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00a4c000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00a07000)
        /lib/ld-linux.so.2 (0x005b7000)
        libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x007ba000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x0079c000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00797000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x007be000)
[Vince@localhost Fri Jun 13 20:13:46 ~]$

Of course, you should see instead:
libGL.so.1 => /usr/lib/libGL.so.1

You may also be missing one of those sym-links because Xorg is looking in the wrong folder for the library - this should tell you.

Yes, unfortunately, that new EXA acceleration is a bit... unstable. BTW, 200 >> 300 FPS = +50% is considered very good.

V