The logo above lies about this page: I am trying to make it cover all of the DRI-supported OSes, so ignore any paragraph prefixed with another OS name. This is a process for troubleshooting the DRI. It is only useful if you do it in order.
Check that the DRM (Direct Rendering Module, the kernel module) is loaded and found your card. Do dmesg | grep drm. You should have several lines of info, with samples below:
[drm] AGP 0.99 on Intel i815 @ 0xe8000000 64MB [drm] Initialized radeon 1.1.1 20010405 on minor 0
Note that that 64MB is not the size of the card's memory, it's the size of the AGP aperture (how much system ram can be accessed by the card if X chooses to use that much).
FreeBSD: If you are using drm-kmod, did you enable the startup script? You needed to move /usr/local/etc/rc.d/drm.sh.sample to /usr/local/etc/rc.d/drm.sh and do /usr/local/etc/rc.d/drm.sh start.
FreeBSD: If kldload <card> (card being one of radeon, tdfx, mga, r128) says Exec format error, check your dmesg for complaints about unresolved symbols. If the unresolved symbols are agp, look at he agp instructions belowFreeBSD:If kldstat shows your card module is loaded but it nothing shows up in dmesg | grep drm, you may not have a supported card. Notable unsupported cards that people are often confused about:
In the above, "updated DRM" means the modules from 4.3.0, or later for some cards. For FreeBSD this means the modules from -current or -stable. For linux, updated DRM is available in the 2.5.x kernel series or from Alan Hourihane's site.
FreeBSD/NetBSD: If you have a card that you think should be supported by the existing drivers but isn't probing, you can do a scanpci -vv and send me the output along with your dmesg, and I'll take a look if it should be supported.
If dmesg | grep drm complains about AGP, you need to check on your
AGP. Do dmesg | grep agp to see what the agp module says.
FreeBSD: If your AGP is probing fine, then you probably have have
device agp in the kernel or loaded from loader.conf. This
doesn't work, so remove it from loader.conf.
FreeBSD: If dmesg | grep agp doesn't show anything about agp,
make sure you have device agp in your kernel (it's default in stable
and current). AGP does not work when loaded as a module after boot.
Linux: If there are no agpgart: lines, compile agpgart into your kernel or load it as a module. If it complains about an unsupported chipset/bridge, make sure you included your chipset-specific agp support when you configured the kernel.
If the DRM is probing correctly, take a look at your XFree86 log. It's located at /var/log/XFree86.0.log. First, make sure the dri module is getting loaded. Running grep dri /var/log/XFree86.0.log | grep LoadModule will show it being loaded. If not, add Load "dri" to the Modules section of XF86Config. Load "glx" is also necessary. If you are having troubles with your changes to XF86Config not having any effect, make sure the XF86Config you are editing matches the one being used according to grep config\ file /var/log/XFree86.0.log
Next, make sure that X is working with the DRM correctly. Look
at the bottom of the XFree86 log where it has lines with [dri], [drm],
[agp], etc. If there are any (EE) errors in there, those are what to
If it complains about the kernel module version, you have to update your kernel modules. For FreeBSD this means either modules from -current or from -stable as described in the install section. For linux, updated DRM is available in the 2.5.x kernel series or from Alan Hourihane's site.
Linux: If you thought you had updated your kernel module and the updated version shows up after you modprobe the appropriate <card>.o, make sure your kernel doesn't have the DRM compiled in. If you dmesg | grep drm it will show multiple versions having been loaded. Recompile your kernel without the DRM and install the updated module again.
Linux: If it says [drm] drmSetBusid failed (7, PCI:1:0:0), Permission denied, people have said that it's due to the modules being built with a different gcc than the kernel. Make sure they are in sync.
If you find a line saying:
DefaultDepth 24 DefaultFbBpp 32as appropriate to your XF86Config's Screen section.
If there are no [dri] lines and it says Direct Rendering disabled, you may be trying to use too high of a resolution. grep static\ buffer /var/log/XFree86.0.log will find a line like: (WW) ATI(0): DRI static buffer allocation failed -- need at least 4608 kB video memory. If so, reduce your resolution or color depth. The kb of video ram necessary for a given resolution/depth is width*height*depth/8*3. (The 3 is for front, back, and depth buffers).
If you are using Intel i8xx hardware and it says:
(WW) I810(0): xf86AllocateGARTMemory: allocation of 1024 pages failed (Cannot allocate memory)You need to have XFree86 allocate more system memory to the integrated graphics. In the Device section of XF86Config, set VideoRam to something higher, for example:.
If you see messages about:
Symbol __glXActiveScreens from module /usr/X11R6/lib/modules/extensions/libdri.a is unresolved! Symbol __glXActiveScreens from module /usr/X11R6/lib/modules/extensions/libdri.a is unresolved!make sure you have Load "glx" in your XF86Config's modules section. If you do have Load "glx", make sure you don't have any of the nvidia binary driver installed, particularly libglx.so*, and reinstall XFree86 if you continue to have problems. If it says Direct Rendering enabled in the log, then the X Server is initializing the DRI fine.
Next, look at a GL program. Set the environment variable LIBGL_DEBUG to verbose, i.e. setenv LIBGL_DEBUG verbose or export LIBGL_DEBUG=verbose depending on your shell. Run glxinfo, which should be included with XFree86. At the top it should show libGL trying to load the driver-specific hw rendering library, like libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/radeon_dri.so. If it isn't doing that, you have replaced your XFree86-provided libGL with some other libGL or it's finding an old libGL from somewhere. Linux: Run ldd /usr/X11R6/bin/glxgears (or glxinfo) and see what libGL it's finding, and make sure it's the /usr/X11R6/lib/libGL one from XFree86. You shouldn't have any libMesaGL* on your system.
If you get:
libGL error: failed to open DRM: Operation not permitted libGL error: reverting to (slow) indirect renderingthen you are trying to run as a user that doesn't have permission to use the DRI (root is the default allowed user). To let all users access the DRI, add the following section to your XF86Config:
Section "DRI" Mode 0666 EndSection
If you have a 3dfx card and it's complaining about libglide3, or there are glide errors, you need to install correct glide for your card as provided by your distribution. Instructions for FreeBSD are on the Install page.
If you are using a radeon and it complains about the module versions and maybe fails on an assertion, you need to update your DRM as in the instructions above.
If it is printing the OpenDriver lines but has some other error, what you do depends on the error. FreeBSD/NetBSD users may be able to get help from me by emailing me at firstname.lastname@example.org with whatever system info might possibly be relevant (OS/release, card, X version, DRI version if any, drm-kmod version if any, application error logs, XF86Config, /var/log/XFree86.0.log, etc.). Otherwise, ask on the dri-users mailing list, information for which is at the DRI website
If you've made it this far, glxinfo should be printing direct rendering: Yes and direct rendering for native GL programs should be working. Make sure that you are running at reasonable settings for your card, and maybe adjust your expectations of speed.
FreeBSD: Linux compatibility has its own set of issues. To debug linux DRI compatibility (i.e. quake3/UT), use /compat/linux/usr/X11R6/bin/glxinfo with LIBGL_DEBUG=verbose set. You should be using -current as of April 25, 2003 or -stable as of May 2nd, 2003. Your linux_dri version should exactly match the X you have installed. If not you'll probably get segfaults. If your XFree86 segfaults, make sure you don't have the linux_glx port installed. If you get coredumps on your system with SSE support (Pentium 3 and up, Athlon XP and up), you may need to set the environment variable MESA_FORCE_SSE to 1 due to what appears to be a bug with our linux compat's signal handling.