Direct Rendering

To verify whether direct rendering is working (just in theory, as on some chipsets it doesn't actually work), run:

grep rendering /var/log/Xorg.0.log

On the older chipsets this should say:

(II) CHROME(0): direct rendering enabled

To verify whether there are any errors:

grep "^(EE)" /var/log/Xorg.0.log

To verify whether there are any warnings:

grep "^(WW)" /var/log/Xorg.0.log

3D

If you can't get the Mesa 3D unichrome driver from git running properly, here are some things to try:

If you're on a 64-bit system, you really need via drm version 2.7.4 or above. You also need the mesa_6_4_branch from git. Also check that unichrome_dri.so gets installed in the correct location, since there may be some confusion as to where it should be installed. Use the LIBGL_DEBUG setting below to see from what location it is loaded and compare with where it got installed.

Check in the X server log /var/log/Xorg.0.log that DRI is enabled.

Check that you really used compatible versions of libdrm and Mesa. [How?]

Run glxinfo It should say Direct Rendering: Yes at some point. If it doesn't, use the environment variable setting export LIBGL_DEBUG=verbose (for bash-type shells) or setenv LIBGL_DEBUG verbose on csh/tcsh and rerun glxinfo to see what is wrong. Usually the 3D driver is not installed properly.

If you get AGP-related errors, check that you have the AGP aperture set to 32MB or more in the BIOS. Also make sure that the AGP driver is loaded before the drm driver. The agp driver is called via_agp.ko unless you're on a K8M/N800 system, where it is called amd64_agp.ko Usually distros will list one of these modules in the file /etc/modprobe.preload

The gears of glxgears may appear to turn slowly even if the printed figures say the framerate is high. This is perfectly normal: the eye is much too slow to see rates above about 30 fps. Trust the figures.

If your cursor seems to disappear or to misrender the background when you move it over a 3D window, it is probably because you are using a color cursor and the openChrome driver is currently not capable of doing hardware color cursors. Instead it falls back to software color cursors, and these are implemented in the X server using extensions that are not compatible with DRI. That is why you see what you see. A workaround is to use monochrome cursors [todo: figure out how].