hard candy
10-06-2004, 11:22 AM
Anandtech (http://www.anandtech.com/linux/showdoc.aspx?i=2229&p=1) had an article dated 10/4/04, that was comparing video cards in Linux, and had some interesting ATI configuration points included and some example configurations for X. I thought maybe some ATI owners could use some tips. (Thank goodness I chose Nvidia)
ATI's drivers came out of the box with several problems. We made the initial mistake of installing and testing the entire suite of video cards with the NVIDIA cards/drivers first. We are not entirely sure why, but even after completely removing the NVIDIA kernel module via NVIDIA's uninstall scripts, we still had persistent errors installing the ATI drivers correctly.
Our first test bed was an nForce3 MSI Socket 939 board. We isolated some of our problems to the agpgart module - for older ATI drivers, we need to load a separate specific AGP module on SuSE 9.1 for DRI to load correctly. On our MSI nForce3 board, this should have been the nvidia_agp module. However, try as we could, we could not get nvidia_agp and fglrx to play well with each other. Some of the issues stem from SuSE 9.1 not recognizing the nForce3 chipset correctly, but some issues may stem from ATI drivers just not recognizing everything correctly. After switching to a Socket 939 VIA motherboard, our problems suddenly disappeared. Of course, we had to re-test our entire NVIDIA suite on the new motherboard (we saved it for last the second time around).
Even by switching to a different motherboard, we were not entirely blessed. Using ATI's driver set from their website yielded some results, but first, we made the mistake of using the fglrx package from ATI's website. ATI's implementation of the X Windows configuration completely upsets SaX2, and X will simply ignore the DRI module when we try to load it. Somewhere between playing with various kernel builds, driver builds and hardware configurations, we finally got it right. Our best success with newest SuSE 9.2-RC3 kernel[1] came from using the RPMs and instructions on the supplement FTP site. The 2.6.8 kernel blew away our boot configuration a few times; for whatever reason, VIA SATA controllers are now recognized as SCSI controllers to the new Linux kernel. Without getting too much into detail, we needed to re-edit our mtab, fstab and grub configuration to a different device; the serial ATA drives suddenly became SCSI drives. We finally no longer had errors on the agpgart driver:
linux:~ # dmesg | grep agpgart
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected AGP bridge 0
agpgart: Maximum main memory to use for agp memory: 941M
agpgart: AGP aperture is 128M @ 0xf0000000
linux:~ #
Footnote
[1] 2.6.8-14-default, you can download it from the SuSE FTP site in the update directory.
Looking back, had we completely destroyed our OS with a new kernel in this manner in the first place with the nForce3 motherboard, we probably would have ended in the same result. Our new SuSE sanctioned ATI configuration still uses the non-GPL fglrx driver (as opposed to the in-kernel radeon driver), but comes with a partially compiled kernel module and is compatible with SuSE's SaX2 configuration. X must be configured with the line below in order for the game to correctly load the DRI driver:
# init 3
(login)
# sax2 -r -m 0=fglrx -b /usr/X11R6/lib/sax/profile/firegl
Enabling 3D acceleration (DRI) still needs to be done manually by editing the /etc/X11/XF86Config file after running the SaX2 utility. Enabling FSAA must be done by editing the XF86Config file by hand as well (see our AA/AF section for details). After a little more than 8 hours of playing with configurations, we hit paydirt.
linux:~ # glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
All in all, just getting the ATI drivers on something that isn't Red Hat feels like way too much work for basic OpenGL support. Keep in mind that we even run SuSE, a RPM derivative - not too different from Red Hat. Even after we got the ATI fglrx drivers working correctly, we had a couple of issues with screen corruption and poor resizing. Below, you can see a screen grab from our ATI frame buffer playing Unreal Tournament at 800x600. The image should not be surrounded by a black border, but rather, stretched to the limits of the screen.
FSAA and AF
Enabling and disabling Full Screen Anti Aliasing and Anisotropic Filtering for both cards was met with varying succes. 4X AA for the ATI cards was enabled by hand in the XF86Config file. We needed to include the additional options for our fglrx device after installing the driver properly:
Option "FSAAEnable" "yes"
Option "FSAAScale" "4"
Option "FSAADisableGamma" "no"
Option "FSAACustomizeMSPos" "no"
Option "FSAAMSPosX0" "0.000000"
Option "FSAAMSPosY0" "0.000000"
Option "FSAAMSPosX1" "0.000000"
Option "FSAAMSPosY1" "0.000000"
Option "FSAAMSPosX2" "0.000000"
Option "FSAAMSPosY2" "0.000000"
Option "FSAAMSPosX3" "0.000000"
Option "FSAAMSPosY3" "0.000000"
Option "FSAAMSPosX4" "0.000000"
Option "FSAAMSPosY4" "0.000000"
Option "FSAAMSPosX5" "0.000000"
Option "FSAAMSPosY5" "0.000000"
Option "UseFastTLS" "0"
Option "BlockSignalsOnLock" "on"
Option "UseInternalAGPGART" "no"
Option "ForceGenericCPU" "no"
Option "EnablePrivateBackZ" "yes"
Pay considerable attention to the EnablePrivateBackZ option. Although documentation for that particular variable seems light, AntiAliasing refused to draw correctly without it. Without enabling that element on our tests beds, nothing would draw to the screen.
You may notice that we purposely have not discussed much about Anisotropic Filtering up until this point. There are currently no driver-level AF features in fglrx. This is a large problem with the Radeon cards in our lineup - but fortunately, we still have trilinear and bilinear filtering.
To enable FSAA for NVIDIA cards, we needed only to set the environmental variable $__GL_FSAA_MODE to 4 (AF is enabled similarly by setting $__GL_DEFAULT_LOG_ANISO). We do not need to restart X to enable FSAA or AF, which is a huge relief for us. However, attempting to find Anisotropic Filtering working correctly in a game setting proved difficult. Perhaps it was the way in which we configured our drivers, or perhaps some fluke in our testing methodology escaped us, but AF for NVIDIA cards did not work.
Since the AnandTech FrameGetter utility by default measures FPS once every second, we modified the source to take screenshots every tenth of a second for this portion of the test. After running the various benchmarks a few times, we had several hundred overlapping frames to choose some comparative screenshots for IQ testing. Below, you can see our capture of a soldier that shows two levels of anti-aliasing. Try as we could, there were no instances of one card rendering AA differently than the other. No driver cheating conspiracies today. Anandtech (http://www.anandtech.com/linux/showdoc.aspx?i=2229&p=1) :)
ATI's drivers came out of the box with several problems. We made the initial mistake of installing and testing the entire suite of video cards with the NVIDIA cards/drivers first. We are not entirely sure why, but even after completely removing the NVIDIA kernel module via NVIDIA's uninstall scripts, we still had persistent errors installing the ATI drivers correctly.
Our first test bed was an nForce3 MSI Socket 939 board. We isolated some of our problems to the agpgart module - for older ATI drivers, we need to load a separate specific AGP module on SuSE 9.1 for DRI to load correctly. On our MSI nForce3 board, this should have been the nvidia_agp module. However, try as we could, we could not get nvidia_agp and fglrx to play well with each other. Some of the issues stem from SuSE 9.1 not recognizing the nForce3 chipset correctly, but some issues may stem from ATI drivers just not recognizing everything correctly. After switching to a Socket 939 VIA motherboard, our problems suddenly disappeared. Of course, we had to re-test our entire NVIDIA suite on the new motherboard (we saved it for last the second time around).
Even by switching to a different motherboard, we were not entirely blessed. Using ATI's driver set from their website yielded some results, but first, we made the mistake of using the fglrx package from ATI's website. ATI's implementation of the X Windows configuration completely upsets SaX2, and X will simply ignore the DRI module when we try to load it. Somewhere between playing with various kernel builds, driver builds and hardware configurations, we finally got it right. Our best success with newest SuSE 9.2-RC3 kernel[1] came from using the RPMs and instructions on the supplement FTP site. The 2.6.8 kernel blew away our boot configuration a few times; for whatever reason, VIA SATA controllers are now recognized as SCSI controllers to the new Linux kernel. Without getting too much into detail, we needed to re-edit our mtab, fstab and grub configuration to a different device; the serial ATA drives suddenly became SCSI drives. We finally no longer had errors on the agpgart driver:
linux:~ # dmesg | grep agpgart
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected AGP bridge 0
agpgart: Maximum main memory to use for agp memory: 941M
agpgart: AGP aperture is 128M @ 0xf0000000
linux:~ #
Footnote
[1] 2.6.8-14-default, you can download it from the SuSE FTP site in the update directory.
Looking back, had we completely destroyed our OS with a new kernel in this manner in the first place with the nForce3 motherboard, we probably would have ended in the same result. Our new SuSE sanctioned ATI configuration still uses the non-GPL fglrx driver (as opposed to the in-kernel radeon driver), but comes with a partially compiled kernel module and is compatible with SuSE's SaX2 configuration. X must be configured with the line below in order for the game to correctly load the DRI driver:
# init 3
(login)
# sax2 -r -m 0=fglrx -b /usr/X11R6/lib/sax/profile/firegl
Enabling 3D acceleration (DRI) still needs to be done manually by editing the /etc/X11/XF86Config file after running the SaX2 utility. Enabling FSAA must be done by editing the XF86Config file by hand as well (see our AA/AF section for details). After a little more than 8 hours of playing with configurations, we hit paydirt.
linux:~ # glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
All in all, just getting the ATI drivers on something that isn't Red Hat feels like way too much work for basic OpenGL support. Keep in mind that we even run SuSE, a RPM derivative - not too different from Red Hat. Even after we got the ATI fglrx drivers working correctly, we had a couple of issues with screen corruption and poor resizing. Below, you can see a screen grab from our ATI frame buffer playing Unreal Tournament at 800x600. The image should not be surrounded by a black border, but rather, stretched to the limits of the screen.
FSAA and AF
Enabling and disabling Full Screen Anti Aliasing and Anisotropic Filtering for both cards was met with varying succes. 4X AA for the ATI cards was enabled by hand in the XF86Config file. We needed to include the additional options for our fglrx device after installing the driver properly:
Option "FSAAEnable" "yes"
Option "FSAAScale" "4"
Option "FSAADisableGamma" "no"
Option "FSAACustomizeMSPos" "no"
Option "FSAAMSPosX0" "0.000000"
Option "FSAAMSPosY0" "0.000000"
Option "FSAAMSPosX1" "0.000000"
Option "FSAAMSPosY1" "0.000000"
Option "FSAAMSPosX2" "0.000000"
Option "FSAAMSPosY2" "0.000000"
Option "FSAAMSPosX3" "0.000000"
Option "FSAAMSPosY3" "0.000000"
Option "FSAAMSPosX4" "0.000000"
Option "FSAAMSPosY4" "0.000000"
Option "FSAAMSPosX5" "0.000000"
Option "FSAAMSPosY5" "0.000000"
Option "UseFastTLS" "0"
Option "BlockSignalsOnLock" "on"
Option "UseInternalAGPGART" "no"
Option "ForceGenericCPU" "no"
Option "EnablePrivateBackZ" "yes"
Pay considerable attention to the EnablePrivateBackZ option. Although documentation for that particular variable seems light, AntiAliasing refused to draw correctly without it. Without enabling that element on our tests beds, nothing would draw to the screen.
You may notice that we purposely have not discussed much about Anisotropic Filtering up until this point. There are currently no driver-level AF features in fglrx. This is a large problem with the Radeon cards in our lineup - but fortunately, we still have trilinear and bilinear filtering.
To enable FSAA for NVIDIA cards, we needed only to set the environmental variable $__GL_FSAA_MODE to 4 (AF is enabled similarly by setting $__GL_DEFAULT_LOG_ANISO). We do not need to restart X to enable FSAA or AF, which is a huge relief for us. However, attempting to find Anisotropic Filtering working correctly in a game setting proved difficult. Perhaps it was the way in which we configured our drivers, or perhaps some fluke in our testing methodology escaped us, but AF for NVIDIA cards did not work.
Since the AnandTech FrameGetter utility by default measures FPS once every second, we modified the source to take screenshots every tenth of a second for this portion of the test. After running the various benchmarks a few times, we had several hundred overlapping frames to choose some comparative screenshots for IQ testing. Below, you can see our capture of a soldier that shows two levels of anti-aliasing. Try as we could, there were no instances of one card rendering AA differently than the other. No driver cheating conspiracies today. Anandtech (http://www.anandtech.com/linux/showdoc.aspx?i=2229&p=1) :)