In order to further Red Hat's commitment to KMS on radeons, I've been adding support for a bufmgr to all 3 radeon 3D drivers.

The bufmgr essentially abstracts the lowlevel buffer management from the state machine of the driver, so we can implement a simple userspace buffer manager which operates on the current system, and a memory managed buffer manager which operates on the GEM kernel API we defined for radeon.

Jerome Glisse and Nicolai Haehnle wrote the initial r300 bufmgr, texturing and mipmap tree code. I decided that instead of trying to port it to r100/r200, I took the opportunity to merge as much of the common code in radeon/r200/r300 drivers.

So armed with piglit to fight regressions and a lack of sleep, I started merging.

So I've pushed the results to the radeon-rewrite branch of mesa, it works for me on all the radeons I've played with in legacy mode.

My future plans for the codebase are:1. get libdrm_radeon on modesetting-gem autodetected 2. Implement radeon/r200 userspace clear code. This is in-kernel at the moment but kms needs it out.3. Play with DRI2 - should already be supported on KMS/GEM stack. I suspect I need to fix some state handling for this.4. make it go fast on kms - work with compiz and a few games for F11.

I've been following your radeon-rewrite branch through cgit and I'm really impressed about the code quality. You improved the code from "copy and paste" to something that uses common code together. Looking forward for your next steps.

I'd also like to help test this. I have a laptop with RS482 [Radeon Xpress 200M] and desktop with RV350 AR [Radeon 9600] if that would be of any help. So are there any instructions on Wiki or somewhere on how to help by testing this.

All the code is available in http://cgit.freedesktop.org/mesa/mesa/log/?h=radeon-rewrite
Simply do:
mkdir /usr/src/mesa
cd /usr/src/mesa
git clone git://anongit.freedesktop.org/mesa/mesa .
git checkout --track -b radeon-rewrite origin/radeon-rewrite
And now build mesa as you usually do (sh autogen.sh && ./configure && make). After that
export LIBGL_DRIVERS_DIR=/usr/src/mesa/lib
and run your program.
!!!Note that I wrote all this from memory and cannot garantuee it is valid!!!

Yes, you will need a kernel with at least GEM (I'm not sure about KMS, and I haven't tested this myself yet). Probably your best bet is to build the DRM modules from git, as well. You probably don't want to do this on anything earlier than 2.6.29.

Really good job you do. Especially thanks that you bring the new life for R200 and R300 graphic cards. I've got RV350 and many people here have still RV250/RV280/RV350 and we don't want to change the cards for another ~2-3 years. When AMD dropped support for R300 hardware in their binary blob I've migrated to yours open source driver and I've just loved it - many things which didn't want to work on AMD/ATI binary driver work out of the box here and even if the driver is 2 times slower on 3D games and has not as many OpenGL extensions as binary driver has I feel it's more responsive in Compiz/KDE Desktop Effects and better 2D. I can finally watch TV from analog TV card with XV and SHM support without flickering or X crashing with good framerate and without noticed CPU usage. What am I missing is Wine Direct3D support as good as in Nvidia binary driver, but I can live with that for now. Keep up the good work. Many thanks from me and friends from Poland.

Unfortunately, fixing Wine3D will be a bit of a challenge, as it was essentially written around the Nvidia drivers. The good news, however, is that it may be possible at some point to implement it directly over Gallium3D.

"Some users reported rendering problems when using the open source AMD/ATIdrivers for their graphics card. Users of ATI graphics cards are advised to try the proprietary Catalyst (fglrx) driver instead."

Some users experienced problems using the proprietary proprietary Catalyst (fglrx)drivers for their graphics card. Users of ATI graphics cards are advised to try the open source AMD/ATI driver instead.