Name: Matrox Millennium G450 Under Linux
Item: Matrox Millennium G450 Under Linux
Author: Jeff Brubaker

Original Link: https://www.anandtech.com/show/623

Matrox Millennium G450 Under Linux

VIEW ARTICLE

by Jeff Brubaker on September 19, 2000 12:00 PM EST

Posted in
GPUs

0 Comments

Introduction

For Linux users, Matrox has been one of the most important video card manufacturers for quite some time. Traditionally, their cards have enjoyed the best support due to their crisp 2D quality and willingness to open their specs, at least to some extent, to Linux developers. Unlike Windows users, Linux relies on the development efforts of the community to develop drivers for their products. Without the benefit of in-house driver development, cards often come to the market long before drivers are available, if ever.

However, things are changing. With the growing popularity of Linux, video card manufacturers are taking notice. For the Matrox G400 and G450, Matrox contracted Precision Insight to develop drivers. While not in-house, the effort was financially supported and ensured proper support for their products under XFree86. Elsewhere, NVIDIA signed a contract with SGI and VA Linux to help codevelop drivers themselves. Their goals were to unify as much code as possible between Linux and Windows. Their drivers are now up to revision 0.9-5, which was released 9/6/2000, and are not based on DRI (although it works similarly). By using the same code base for both Linux and Windows drivers, they have quickly become one of, if not the fastest performing Linux 3D video card.

So, the question remains, with the advanced NVIDIA drivers available, does Matrox still hold the crown of "best supported card under Linux?" Further, since the Linux gaming market is still quite small, is 3D acceleration the most important factor in determining what card to get? Now that XFree86 4.0.x is available and Linux users have proper multi-monitor support through the Xinerama extension (that combines multiple displays into a single logical root window), multi-head has become the thing to do. It seems almost every website in Linux land has a screenshot at 2560x1024 or 3840x1024 resolution. Further, Matrox has recently released G450 drivers for Linux that support their Dual Head functionality. Will this become the card to have?

The Contenders

Matrox G450

Click to Enlarge

NVIDIA GeForce2 MX

Click to Enlarge

Driver Howto

If you haven't tried to put together a working XFree86 4.0.x setup, it can be quite an effort. Distributions have been slow to create packages and drivers are evolving faster than releases. Combine this with the fact that DRI drivers typically require a kernel module that must be specifically compiled for your kernel and the process gets even more involved.

With Matrox cards, there is a further consideration. XFree86 comes with DRI enabled drivers in XFree86 4.0.1 that work with all Matrox cards prior to the G450 (DRI only on the G200/G400). However, recently Matrox released a driver on their own site for the G200/G400/G450 with support for Dual Head and more advanced 3D acceleration. Further, there's the DRI CVS tree, which has been rolling the Matrox changes back into their code which supports previous Matrox cards as well.

Why worry about those older cards? Some users would like to use their older Millennium IIs to drive a third monitor, with a G4x0 driving the other two. An experienced Linux user would immediately consider using the Matrox drivers with the G4x0 and the XFree86 drivers with the Millennium II, but this isn't possible as the two drivers share the same name and symbols. Hacks exist to rewrite all the exported symbols, but we have yet to verify whether or not they work.

So where do you start? This test focuses on XFree86 4.0.1, compiled locally on the test machine, combined with the drivers from Matrox's site. Since the test machine runs Red Hat 6.2, agpgart was already installed. For those of you new to this, agpgart is the kernel AGP/GART interface module. It is required for most DRI modules and requires patching your kernel if you have a 2.2.x kernel, or using 2.3.51 or higher, which come with the module included. Note that you only need agpgart and mga kernel modules if you plan on using direct rendered OpenGL. After quite a while compiling (XFree86 is huge), it was ready to go.

The first problem was that the second display could only achieve 60Hz on at 1280x1024 which, to me, is unacceptable. Apparently, the Matrox drivers hard code the speed of the secondary RAMDAC to 112MHz. After changing the guilty line of code, line 1901 of mga_driver.c, to 200000 (for 200MHz, the secondary RAMDAC speed of the G450), the secondary display came up at 75Hz. Why this would be fixed at compile time is beyond us.

Dual Head setup is relatively simple once you've seen it, but at first it can be quite intimidating. Here's an excerpt from our test XF86Config:

  Section "Device"
    Identifier  "G450-1"
    Driver      "mga"
    BusID       "PCI:1:0:0"
    Screen      0
  EndSection

  Section "Device"
    Identifier  "G450-2"
    Driver      "mga"
    BusID       "PCI:1:0:0"
    Screen      1
  EndSection

  Section "Screen"
    Identifier    "Screen 1"
    Device        "G450-1"
    Monitor       "Sun"
    DefaultDepth  16

    SubSection "Display"
      Depth       16
      Modes       "1280x1024" "1024x768" "800x600" "640x480"
    EndSubSection
  EndSection

  Section "Screen"
    Identifier    "Screen 2"
    Device        "G450-2"
    Monitor       "ViewMate"
    DefaultDepth  16

    SubSection "Display"
      Depth       16
      Modes       "1280x1024" "1024x768" "800x600" "640x480"
    EndSubSection
  EndSection

  Section "ServerLayout"
    Identifier    "DualHead"
    Screen        "Screen 1" LeftOf "Screen 2"
    Screen        "Screen 2"
    Option        "Xinerama"
  EndSection

Using the G450

When the card was finally set up, X started up with Xinerama and fired up both monitors like it was supposed to, but reversed them. What was supposed to be the second display was coming out of the port labeled "Monitor 1" on the card. No big deal but this setup remained even after leaving X. Now the secondary display was showing the console. This was quite annoying actually because the second display is an old Sun GDM-20D10 monitor that can't handle such frequencies. Other than the switched monitor voodoo, the card worked extremely well. There were no display defects while using Dual Head and everything worked just as in the other machine which uses two video cards for dual head display.

Desktop screenshot
Click to Enlarge

Here's a (really, really big) screenshot of X running with Dual Head enabled. The window manager is Enlightenment. Other applications include EFM (file manager), GIMP (paint program), Eterm (terminal), GKrellM (system monitor), XMMS (MP3 player) and Gabber (Instant messenger).

So why bother with Dual Head? The best use for Dual Head has got to be for the developer. Having all of your code on one monitor while debugging or referencing documentation on the other is absolutely amazing. Even for the average user, it's nice to have your mail on one screen along with a program such as Gabber to perform instant messaging while web browsing or working on the other screen. Typically, one must increase resolution to the point of being unreasonably small on their monitor to achieve desktop real estate. With Dual Head, it's possible to read everything AND have the real estate, assuming you have the monitors to handle the duty. Still, with old workstation monitors going for dirt cheap these days, it should be possible for almost anyone to have a dual head machine. Further, Matrox now supports DVI and TV out with their drivers, making one's Dual Head options far more interesting under Linux. TV output is great for gaming, where screen size is more important than resolution most of the time.

Now, remember, this is a 2D only, Xinerama display. For accelerated OpenGL using DRI, one has to forego the Xinerama extension. This should mean that the primary display can be accelerated and while the secondary display is unaccelerated. We did not try this, but we did try with Xinerama enabled, just for the off chance that indirect rendering might work. Unfortunately, the result was software rendered OpenGL for everything.

The following is an example XF86Config excerpt that enables DRI:

  Section "Module"
    Load    "dbe"
    Load    "type1"
    Load    "freetype"
    Load    "extmod"
    Load    "glx"
    Load    "dri"
  EndSection

  Section "DRI"
    Mode    0666
  EndSection

The two modules related to 3D acceleration are the last two. The DRI section allows non-root users to use DRI. The two most common mistakes with people trying to get DRI to work is missing this in their XF86Config file and using Mesa's libGL.so files. Let us expand a little on that second issue. Most distributions ship with Mesa, a free OpenGL implementation. Without the proper DRI hooks, you won't see any 3D acceleration. So, when installing XFree86, make sure to check in /usr/lib and /usr/X11R6/lib to make sure the right version is there. A good way to check is to simply use strings, strings libGL.so.1 | grep DRI. If anything comes back, you're using the right version.

The Test

Red Hat Linux 6.2 Test System
Hardware
CPU(s)	Intel Pentium III 750
Motherboard(s)	AOpen AX6BCPro Gold
Memory	128MB PC133 Corsair SDRAM (Micron -7E Chips)
Hard Drive	Western Digital Expert WD 313600 13.6 GB 7200 RPM Ultra ATA 66
Video Card(s)	Matrox Millennium G450 NVIDIA GeForce 2 MX 32MB
Ethernet	Linksys LNE100TX 100Mbit PCI Ethernet Adapter
Software
Operating System	Red Hat Linux 6.2
Video Drivers	Matrox Millennium G450 32MB - 1.00.001 Beta NVIDIA GeForce2 MX 32MB SDR - 0.9-5
Benchmarking Applications
2D	Xmark93 (using x11perf) Xstone (using xbench)
3D	Evas Gears Quake III Arena

2D Performance

There is strong need at the moment for standard X benchmarking tools. A few have sprouted recently to help address this, but for now, we're sticking with the old standards, Xmark93 and Xstone. Xmark93 is based on results from x11perf while Xstone is based on xbench.

xbench results

There are two things to notice here.

First, notice the slower scores of the Xinerama display. Yes, adding displays doesn't come free, even though this benchmark took place entirely on the primary display.

Second, the GeForce2 MX killed the G450, scoring a 33% higher in overall xStones rating. Matrox has the best track record with XFree86 drivers, but they're completely dethroned with this performance. Sad but true.

Xmark93 results

Again, we see the NVIDIA outperform the Matrox, this time by 31%.

3D Benchmarks

For benchmarking 3D, we included two tests that you may not know.

First, gears, which is a simple OpenGL test application that comes with Mesa. It's particularly useful given its simplicity is a good way of testing raw triangle throughput.

Second, with OpenGL acceleration becoming more and more common in Linux, developers have started taking advantage of it for more than just 3D. In particular, Rasterman, creator of the Enlightenment window manager, has written a canvas library called evas that can utilize OpenGL for image compositing and raw rendering. The result will be a window manager (Enlightenment) and file manager (EFM) that is accelerated via OpenGL. Evas comes with a test application, evas_test, that we used for benchmarking. Unlike gears, which is purely polygons and no texturing, evas_test is almost the complete opposite, stressing the texturing of the card more than raw triangle throughput.

Finally, Quake III will round out the testing.

It should be noted that the first version of Matrox's drivers (and all drivers included with all current XFree86 releases) left the card running at whatever clock speed it booted at. For the G400 and G450, that meant you were running at approximately half the speed of any Windows machine, which speeds up both the core and memory clock to production levels upon driver initialization. With the latest driver release from Matrox, this issue has been addressed. According to Matrox themselves, this happens within Hallib -- a proprietary library that may be optionally linked with the XFree86 drivers. So, it is possible that even future drivers may not set the clock to production levels accordingly unless they have specifically been linked with this library. Unfortunately, this is unlikely to be the case unless either you or your distribution has compiled it specifically themselves.

Gears results

No question, the G450 is absolutely demolished. There is no texturing here, only raw triangle throughput. Although the test was run at 1280x1024, gears (by default) runs in a rather small window. We left the window size alone as it is easier to apply in comparison to other figures you may see on mailing lists, etc. Typically, this is a good measure of bus efficiency because it's definitely not fill rate limited. However, in this case, the GeForce's T&L engine keeps triangles from being sent across the bus. Score this one up to hardware superiority.

evas_test results

We were actually really looking forward to these benchmarks. For those users that aren't gamers, this is where they are going to get the most use out of OpenGL acceleration.

At low resolution, the NVIDIA is destroying the Matrox at almost a perfect factor of 2. However, at 1280x1024, it performs "only" 1.6 times faster than the Matrox. This here we see the fill rate/memory bandwidth limitations of the GeForce2 MX coming into play. Still, it's plenty to take care of the G450.

Also, note that this benchmark has a very low triangle count. What is important here is texturing speed, which needs memory bandwidth to achieve a proper fill rate. Matrox's G400 MAX has gobs of memory bandwidth and would probably perform well here. The G450 is similar but it's still not enough to dethrone even the GeForce2 MX.

Quake III Arena results

Ok, ok. This is a "corporate" card and it's not meant for playing games. Still, makes for good comparison reading. No real surprise that the GeForce2 MX dominates once again.

Conclusions

What can we say? The cheaper NVIDIA GeForce2 MX beat the Matrox G450 in every category tested. The only redeeming value of the G450 is Dual Head. For some, that will be the killer feature that may cause you to pick the slower card for your own machine, however this probably doesn't apply to most users out there. We were extremely surprised to see the G450 lose to the GeForce2 MX in 2D performance. Given NVIDIA's stress on 3D acceleration, we did not expect to see much optimization in their drivers for 2D.

Still, the progress 3D acceleration has made under Linux in the last year is tremendous. We're looking forward to the DRI 2 and future supported products from Matrox and NVIDIA. Maybe someday you'll be able to have a three headed monster of a computer running a hardware accelerated window and file manager.