The irregular Radeon Development Companion

Update dri-log Android app

tirdc — Sat, 24 Aug 2013 13:55:04 GMT

I'd like to announce an update for the dri-log Android app users, the mobile version the DRI IRC log. The app recently gained with a complete redesigned UI and now is in a really good state for everyday use. Feel free to test it, use it, grab the code (GPL-2) or report bugs and feature requests. It will work from Android 2.2 (Froyo) and later and should be good to use one phones and tables.

Clover moves to the main mesa repository

tirdc — Sun, 01 Apr 2012 22:04:04 GMT

Until now Clover was developed in a separate git repository (and some forks on github as well). But today Francisco Jerez started preparing to add Clover to the mesa tree. Right now the work is happening in the 'gallium-compute' branch. Just a few hours ago the Clover state tracker was imported into that branch.

Right now one still needs a separate branch to use this state tracker, but it's a good sign that Colver is finally moving upstream (i.e. the mesa git repository). And there are also customizations to gallium to allow the AMD LLVM backend to be used. All in all: great achievement.

DRI-log Android App

tirdc — Thu, 29 Mar 2012 18:02:03 GMT

Did you ever wonder what is discussed between graphics hardware developers? If so, you might have found the IRC Logs. It is a handy and small web tool to read IRC logs of #dri-devel, #radeon and #nouveau. It is also open source (GPL-2) so you could easily host your own IRC log webpage.

But today everybody just loves to use Apps for everything, because Apps provide direct access to information you are interested in. That's why a DRI-log App was written. It is a free of charge Android App, supporting Android 2.2 and newer. But what can be done with it? It allows show the IRC log of selected users, so you can easily follow the latest communication regarding your favorite topics.

Feel free to test this App and give feedback!

OpenCL on r600g

tirdc — Mon, 05 Mar 2012 20:38:40 GMT

Just a quick note about the great new of OpenCL running on R600+ hardware using open source drivers:

http://dummdida.blogspot.com/2012/03/they-did-it-smallish-opencl-example.html

It's great to see that the work done over the years is slowly but finally reaching the (almost) average user.

Setting the power_profile for your Radeon graphics card using systemd

tirdc — Sun, 19 Jun 2011 08:52:08 GMT

As of now pretty much everyone has heard of systemd, the next generation init system for Linux. Next to the fact that if provides a really fast boot (on different systems tested approximately 50% of the original boot time) and a clean solution for dependencies of services it also offers the capability to write services in a very simple manner. So today we are going to write a simple service to set your power profile (as introduced last year). Note that you (obviously) need a systemd enabled system like Fedora 15.

First of all we need to know how to set set power profile. This requires three things: a fairly recent kernel, a Radeon graphics card that supports power modes on Linux and sysfs enabled in your kernel. A simple way to test this is to execute the following command:

test -f /sys/class/drm/card0/device/power_profile && echo "power_profile supported" || echo "power_profile NOT supported"

Note: This assumes that your Radeon card is the "first card" (i.e. "card0"). This might vary from system to system.

The will show you if the power modes are supported by your system. If your system is supported you need two files:

1.) The systemd service file in /etc/systemd/system/radeon-power_profile

[Unit]
Description=Radeon Power Profile

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/radeon-power_profile low

[Install]
WantedBy=multi-user.target

2.) A small helper script to set the power mode in /usr/local/sbin/radeon-power_profile

#!/bin/sh

EXEC_NAME=`basename $0`;

TARGET="/sys/class/drm/card0/device/power_profile"
CURRENT_PROFILE=`cat ${TARGET}`

append_profile() {
        local PROFILE=$1
        echo -n "  ${PROFILE}"
        if [ "x${CURRENT_PROFILE}x" == "x${PROFILE}x" ]; then
                echo -n " (current)"
        fi
        echo
}

if [ $# != 1 ]; then
        echo "usage: ${EXEC_NAME} "
        echo
        echo "Valid profiles:"
        for AVAILABLE_PROFILE in low high default auto; do
                append_profile ${AVAILABLE_PROFILE}
        done
        exit 0
fi

PROFILE="$1"

if [ "x${PROFILE}x" == "xlowx" ] || [ "x${PROFILE}x" == "xhighx" ] || [ "x${PROFILE}x" == "xautox" ] || [ "x${PROFILE}x" == "xdefaultx" ]; then
        echo "${PROFILE}" > ${TARGET}
else
        logger "[${EXEC_NAME}] WARN: Invalid power_profile '${PROFILE}'"
        exit 1
fi

exit 0

Note: If your card is not "card0" you need to change the value of TARGET to the proper value.

After you create the scripts you should test if this works for you. The service is meant to set your power mode to low which is the best for mobile devices running on battery or to cool down your system. To test the service call:

/usr/local/sbin/radeon-power_profile

This will print out which profile is currently active ("default" in most cases). Now you can start the service

systemctl start radeon-power_profile.service

This will most likely cause a single flicker of the display (this might be a bug as it does not happen when GPU and memory clock changes happen on Microsoft Windows). After that a second call to /usr/local/sbin/radeon-power_profile should show your clock is now at "low". Verify that your system is running stable and smooth as before. Note: Setting the power mode to low will obviously cause your 3D rendering to be slower. If everything works as expected you can enable the service by default using

systemctl enable radeon-power_profile.service

Now your system will set the power mode during boot. On my systems it really extended the battery life time and my passive (fan-less) card went from 70°C to 45°C.

Updates to libtxc_dxtn

tirdc — Fri, 11 Mar 2011 20:36:13 GMT

Marek Olšák has made some bug fixes to the libtxc_dxtn library (a library for mesa to allow S3TC). First of all you can download the updated version from http://people.freedesktop.org/~cbrill/libtxc_dxtn/libtxc_dxtn-1.0.0.tar.gz. Next to that the source code location changed (the code can be found at http://cgit.freedesktop.org/~mareko/libtxc_dxtn/). Marek also replaced the build system of the library by autotools, but this is not released yet.

A recent discussion about if this library should be added to mesa shows that this is not a desired option. This is because it would require the end user to recmpile the whole mesa instead of this single package.

Getting libtxc_dxtn.so

tirdc — Wed, 13 Oct 2010 18:49:35 GMT

Sadly the site http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html is no longer available.

I got the latest release form my local archive and put it to http://people.freedesktop.org/~cbrill/libtxc_dxtn/libtxc_dxtn070518.tar.gz (md5sum 03beb907c13df6484cde210ce219f4b8) for anyone interested.

I also put a copy of the website to http://people.freedesktop.org/~cbrill/libtxc_dxtn and updated the links to point to the freedesktop DRI-pages instead of the abandoned sourceforge ones.

Gallium R300 as drop-in replacement

tirdc — Thu, 26 Aug 2010 09:34:52 GMT

Dave Airlie made a small commit changing the name of the R300 gallium driver from radeong to r300.

And what does that mean? It basically means that the classic r300 driver and the gallium based one share the same filename. So you can switch between the two drivers by simply replacing the one with the other.

This is really helpful for developers. And it might also be the first sign that the gallium based driver might become the default driver for r300.

Update:

From an anonymous comment:

It also means that you cannot easily package both drivers in rpm packages.

f-spot rant

tirdc — Sun, 22 Aug 2010 12:27:14 GMT

This is a totally radeon-unrelated rant:

<rant>

I decided to import some old photos into f-spot today to check for duplicates and organize them to folders corresponding to the date (i.e. yyyy/mm/dd). I assumed that f-spot would read the EXIF-metadata to extract the date (which is what it did before). After the import I was shocked to see that all images where put into 2001/01/01 ... which is totally wrong (the pictures dated 2005)! After looking at the images names (e.g. "01010008.jpg") I found out that the date was extracted from the filename (which is wrong as the camera does not name the images by date but by whatever else). I though: Ok, forget f-spot and let's use shotwell. Sadly shotwell imported the pictures into the same folders. I looked at the exif metadata of the images before and after the f-spot import ... before the date was correct, after the import the date was wrong.

f-spot replaced the exif timestamp by something that it assumed to be the correct timestamp. That's really evil.

Next to that f-spot was not able to import a large library (~10000 pictures) without using ~2.5GB RAM ... which caused my system to be swapping a lot (while still importing). This slowed down importing a single photo to ~5 seconds. Unusable.

I happily dropped f-spot and will never return. Shotwell performs much better (though it's still not as feature-rich). I'm happy to use a .NET/mono application less and I can only recommend that to you, too.

</rant>

Next to that Jerome Glisse and Dave Airlie keep rocking implementing r600g.

r300g performance

tirdc — Tue, 15 Jun 2010 07:37:42 GMT

Lately Marek Olšák has been focusing on r300g performance. He did a bunch of commits the last days that remove useless code and duplicated security checks. While doing so he also wrapped some debugging code to be enabled/disabled at compile time.

When a developer is focusing on performance this is generally a good sign, because it basically means that the groundwork is done.

On his way he also rewrote occlusion queries. The following commit line shows his intention:

This fixes flickering in Enemy Territory: Quake Wars. The driver now renders everything correctly in this game and the graphics is awesome.

I'll most likely grab myself a copy of the Enemy Territory: Quake Wars demo and test his latest achievements.

gdm multihead xrandr workaround

tirdc — Fri, 04 Jun 2010 06:38:14 GMT

This is totally unrelated to Radeon development, but I couldn't find a good guide for that.

I'm using a Laptop with an external TFT attached to it for my work. It works great using gnome-display-properties to setup the displays when I'm logged in. But it really lacks a "Apply for all users" setting. So it always bothered me that gdm was using mirror mode (or clone mode) for the login. That looks really awful. And since I'm not a big fan of hard coding display settings in my xorg.conf(.d) (and the external display is not connected all the time as this is a laptop) I came up with the following solution:

1.) Open /etc/gdm/Init/Default in your favorite editor

2.) Put the following code right before "/sbin/initctl -q emit login-session-start DISPLAY_MANAGER=gdm"


VGA1_PRESENT=`xrandr | grep "VGA1 connected"`
if [ "x${VGA1_PRESENT}x" != "xx" ]; then
        xrandr --output LVDS1 --auto --pos 0x0 --primary
        xrandr --output VGA1 --auto --right-of LVDS1
fi

3.) Restart X.org

There might be better solutions to this but I could not find any. I hope it helps other that face the same issue.

IRC log interruption and updates

tirdc — Tue, 01 Jun 2010 23:01:50 GMT

Due to technical reasons (the logging daemon was not running) the IRC logs of the last two days are missing. I fixes that and now my favorite site is back online.

Now to the interesting part:

The r300g driver keeps moving forward thanks to Marek Olšák. He's picking up the work that Corbin Simpson started and implements more features and improves stability. He also started looking at the r600g driver started by Jermone Glisse (and others).

Jerome now work for Red Hat after he finished his academic studies. I'm not sure what he's doing exactly but the r600g was done in his free time.

Dave Airlie is doing a great job maintaining the DRM stuff in the kernel. The merge window for 2.6.35 is just over and he got plenty of good stuff pushed upstream. He's also doing experiments to do TFP in the software rasterizer.

Corbin is our 'information dispatcher'. Whenever a user pops up on IRC having a question or a weird problem Corbin is on the spot delivering information to users and gathering information from users.

And finally Alex Deucher is still at AMD/ATI helping out with information and documentation.

We also saw contributions from Maciej Cencora about 2 month ago regarding bugfixes in the class r300 driver.

(I'm sure I missed some people involved in this effort to bring free open source drivers for ATI/AMD Radeons to the world)

Generally speaking: The progress on this topic might be slow, but static. New features keep popping up, performance improvements are made from time to time. I completely dropped fglrx from my system some time ago and I'm using compiz on an old X1650 graphics card without any flaws.

Good job, guys! Thank you!

dri-devel IRC log back up

tirdc — Thu, 01 Oct 2009 21:17:40 GMT

I could restore most parts of the frontend (major parts written in Javascript) from google cache so I proudly present the quick and dirty frontend to the dri-devel IRC logs. I'm currently investigating in using the logs from pq and jcristau from IRC to restore the most recent logs. A big "Thank you" goes to both of these guys. Another "Thank you" goes to krh who happily tested if the logging works and was the first to notice that is was back :-)

End of dri-devel IRC logs

tirdc — Thu, 01 Oct 2009 06:57:34 GMT

As noted by Daniel Stone and Adam Jackson people.freedesktop.org went down due to power failures and therefore lost /home. Unfortunately this was the main hosting place for the dri-devel IRC logs. Unfortunately again, there are no backups. What does this mean?

All logs are gone (more than 2 years)

The PHP frontend is gone

The IRC logging tool is gone

I currently don't have the time or the will to set it up again so I'll add a redirect to the (IMO) completely crappy phoronix IRC logs.

Commit messages like commands

tirdc — Fri, 28 Aug 2009 14:18:31 GMT

A colleague recently asked me why I'm using commit messages that sound like commands or work orders (e.g. "Fix bug XYZ", "Replace method X by Y", etc.). I was wondering myself how I came to do that. So I started looking at http://cgit.freedesktop.org/ and pick several repositories. Among them mesa and glitz. All of these use this comment style. Next I looked up http://git.kernel.org/ and found that the repositories found there also use this commit message style.

Is this the normal way to express something you've done? I'm not a native speaker, but thinking about it I came to the conclusion that "Fixed bug XYZ" and "Replaced method X by Y" sound better to me.

Dear Interweb, what do you think?

An now to something completely different

tirdc — Wed, 01 Jul 2009 21:26:31 GMT

(I know, this blog is supposed to hold news about radeon development, but I just read something really cool on IRC)

09:02 #dri-devel: < Weiss> awesome - first picture on the screen using KMS on my FreeRunner! :D

Yes, that's right. KMS is being worked on to run on the OpenMoko FreeRunner mobile devices. It's especially cool since I own such a thing :-D

HW TCL glxgears in gallium

tirdc — Tue, 09 Jun 2009 14:01:13 GMT

Do I need to add something else? Yes? Ok. Corbin Simpson got to the point where you can run glxgears on top of a gallium accelerated mesa. He figured out what the actual issues were and pushed the changes to git a few hours ago. Good job, Corbin!

Next to that Dave Airlie will be looking into gallium, too. He's interested in porting over code (the fragment shader) form the radeon-rewrite branch of mesa to gallium to see if there are any performance improvements. Corbin objected though. He thinks that this part of code should be rewritten so that it could be maintained and extended. Currently nobody is working on it, so we'll see what the future brings.

Forcing software rendering

tirdc — Sun, 17 May 2009 08:33:14 GMT

Once in a while I need my system to do software rendering and not using any hardware acceleration. A few years ago (before the age of AIGLX) we had a environment variable named LIBGL_ALWAYS_INDIRECT. But that does not disable hardware accelerated rendering. And since I'm forgetting the new variable to force software rendering every time I need it I'm going to explain both here.

LIBGL_ALWAYS_INDIRECT

This variable is used to force an application to always go the indirect rendering path. This means that the libGL (i.e. mesa) does not access the hardware directly but uses the X-servers GLX protocol for the access. The X-server will then use the hardware to render the request.

LIBGL_ALWAYS_SOFTWARE

This variable causes libGL to always use the swrast driver to render the frame in software. This will use no hardware acceleration (i.e. GPU acceleration) at all.

I hope I can finally remember it now :-)

edit:

Of course there is another important environment variable:

LIBGL_DRIVERS_PATH

This variable causes mesa to search in the given directory for DRI drivers. This is handy when doing development since you can have a working driver installed by default and test your driver without breaking your installation.

edit from Corbin Simpson:
Two more useful ones for Radeon people:

RADEON_SOFTPIPE, when set, forces the Gallium Radeon driver into softpipe mode. This makes it quite slow, but it won't ever misrender or die. It even runs glxgears well.

RADEON_NO_TCL for Gallium or R300_NO_TCL for classic r300, will disable HW TCL even if you're not on an IGP chipset. This is useful for testing shaders, and doubly useful on Gallium since HW TCL is very broken there.

tirdc — Sat, 09 May 2009 22:13:36 GMT

Corbin Simpson has been working on getting Gallium for Radeon into a more stable shape. Today he got the non-tcl code running more or less stable.


00:47 #dri-devel: < MostAwesomeDude> Okay, so with what I've just pushed, you can run glxgears with RADEON_NO_TCL for minutes upon minutes. Maybe even longer, didn't really try. Of course, it's still microgears.
00:47 #dri-devel: < MostAwesomeDude> But yeah. BO handling's pretty stable now.

Testing Jeromes Code

tirdc — Sat, 09 May 2009 22:09:46 GMT

I took the time to test drive Jerome Glisses KMS/TTM/CS code. From a first test it is solid and working fine. I haven't had a crash or lockup, so I'm pretty happy with the code. I don't have any performance issues that bug me. I use it for my every day usage at my private computer and I'm actually writing this entry while using it. So for me it's definitely ok for every day usage as long as you can accept a few issues:

As you can see in this picture there there seem some issues in the radeon-rewrite branch. I only could trigger this in blender.

I noticed a few rendering issues when looking web sites using epiphany that use background images for the body. Nothing worse because only the background looks weird while the content is looking normal.

Video scaling is broken. You only see the upper left quarter of the video. As you can see in this picture clipping caused by windows in front of the window cause an even more strange behaviour. The upper part seems to be working more or less fine. The rest is ... well, weird :-)

And last but not least:

glxgears is noticably slower ... but who cares? glxgears is not a benchmark. And ioquake3 bases games are running slower without me ever noticing it.

Respecting the changes done to radeon this is a rather short list of issues. Large central parts of the radeon driver at all levels have been rewritten. There is a new kernel module using TTM and providing KMS. You got a brand new command submission method used by the DDX and by mesa. You are using DRI2 and a rewritten radeon mesa driver. I must admit that I'm pretty impressed of the stability of such early code. Let's say thanks to Jerome Glisse, Dave Airlie, Nicolai Haehnle, Alex Deucher and who else was involved working on the radeon code. Thanks guys!

R300 gallium progess

tirdc — Sat, 04 Apr 2009 22:40:54 GMT

Today Corbin simpson announced the following:


02:45 #dri-devel: < MostAwesomeDude> To anybody that cares: r300-gallium now renders in both HW and SW TCL modes. Go check it out, lemme know if/when it locks up.

This means you should be able to run simple tests programs like glxgears now. Don't expect any big features right now but we are (slowly) moving towards that.

Source

Nearing OpenGL 1.4 support

tirdc — Mon, 16 Feb 2009 02:55:14 GMT

The open source radeon driver is currently supporting all featuresfor OpenGL 1.3 support. This means that all features required by the specification were written and are available in the driver. But the driver has been in state for a long time. So what is missing for OpenGL 1.4 support? Or even OpenGL 2.0? Well, as we could read today on IRC:


08:14 #radeon: < osiris_> osiris_: so were almost there with opengl1.4 support
08:14 #radeon: <osiris_> talks to himself :/
08:15 #radeon: < osiris_> as airlied said with his recent work on radeon-rewrite it should be pretty easy to add occulsion query,pbo and fbo support
08:16 #radeon: < osiris_> so only glsl support will be necessary to advertise opengl2.0

(I really love the second line of this statement, it just made me laugh)

Well, osiris has been working on point param and foog coord support. And he is making good progress. Today he gave a patch to Nicolai Haehnle to test point param on TCL capable hardware and it worked exactly as the software rasterizer from mesa.

It's really great to see how fast the development on radeon is going forward, both in features and code quality. So we really have to thank you guys for putting so much effort into this project. Thanks!

Gallium on Radeon coming along

tirdc — Mon, 12 Jan 2009 12:28:05 GMT

Corbin simpson has been working hard on getting Gallium to run after he finally managed to build it. Today we could read the following lines:


01:47 #dri-devel: < MostAwesomeDude> airlied: Awesome. Got my pipe to build, gonna start trying to get things drawing.

So what does it do right now? Well, to be honest: Nothing. But it's the point at where the groundwork should be (mostly) done and development can focus on actually implementing features. You can watch Corbin's progress in his mesa branch.

Source

Branches

Speaking of branches, radeon development is right now happening in many places. It's hard to tell where to start since different developers are working at different features at different places. This is even agreed by leading radeon developers like Jermone Glisse.


03:15 #dri-devel: < glisse> way too much branch in way too much place

Radeon developers try to avoid conflicts with intel development (happening in the official mesa and drm trees) by using seperate private repositories. This avoids regressions in the intel side but increases complexity of the development process. The nouveau project does it's development in the official trees, too.


00:49 #dri-devel: < pq> with Nouveau it's easy: just use drm.git drm.ko and nouveau.ko, and Nouveau's latest DDX

Let's hope the work being done is sooner getting stable and will be slowly merged over to the official branches.

Testing Gallium

I'll try to explain how to play with Gallium/KMS/DRI2/GEM/TTM by choosing the right branches. Note that this is for testing and not every day usage. I can't tell if I get it right since I never did this myself. I can't test any of the commands listed below as I'm writing this on a win32 system.

First of all you need a Radeon KMS and GEM capable kernel. These are not yet available in any kernel release (and won't be in 2.6.29) so you need to clone the following tree.


mkdir /usr/src/linux-radeon
cd /usr/src/linux-radeon
git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git .
git checkout --track -b drm-rawhide origin/drm-rawhide

Now you need to build and install this kernel. Note that it's a 2.6.28-rc9 (IIRC) so it's not recommend for every day usage. You might also need to install GEM-capable kernel headers. There might be specific instructions for you distribution.

After that you need a modesetting capable libdrm.


mkdir /usr/src/drm
cd /usr/src/drm
git clone git://anongit.freedesktop.org/mesa/drm .
git checkout --track -b modesetting-gem origin/modesetting-gem

Now you need a GEM aware DDX (2D X.org driver). I'm not sure which one is the correct one.


mkdir /usr/src/xf86-video-ati-airlied
cd /usr/src/xf86-video-ati-airlied
git clone git://anongit.freedesktop.org/~airlied/xf86-video-ati .
git checkout --track -b radeon-gem-cs2 origin/radeon-gem-cs2


mkdir /usr/src/xf86-video-ati-glisse
cd /usr/src/xf86-video-ati-glisse
git clone git://anongit.freedesktop.org/~glisse/xf86-video-ati .
git checkout --track -b radeon-gem-cs-dri2 origin/radeon-gem-cs-dri2

Both should be more or less the same, i.e. DRI2, KMS and GEM capable. This work will likely be done for xf86-video-radeonhd at a later point, too.

Finally you need a Gallium Mesa tree.


mkdir /usr/src/xf86-video-ati-glisse
cd /usr/src/xf86-video-ati-glisse
git clone git://anongit.freedesktop.org/~csimpson/mesa .
git checkout --track -b gallium-0.2-radeon origin/gallium-0.2-radeon

This might lead you the right way, or might eliminate your whole disk. There are no guarantees on this guide.

LLVM gallium backends

tirdc — Mon, 29 Dec 2008 00:07:42 GMT


09:09 #dri-devel: < MostAwesomeDude> F*** yes! Got my LLVM backend to build!

With these Corbin Simpson (MostAwesomeDude on IRC) today got his R300 LLVM shader backend to compile. You wonder what a LLVM shader backend is? Well, in the gallium world shaders (both vertex and fragment) are translated into a hardware independent and shader independent format. This format will then be sent to LLVM to perform optimizations on them and, using a backend, turn it into a hardware dependend shader. Corbin is currently working on writing the vertex shader LLVM backend. But don't expect to much yet:


09:43 #dri-devel: < mattst88> MostAwesomeDude, tell us more, what's it do, etc.
09:45 #dri-devel: < MostAwesomeDude> mattst88: Segfault.

For the full details read the IRC logs.

The way to bufmgr

tirdc — Mon, 04 Aug 2008 07:28:32 GMT

Recently more and more people start working on dri_bufmgr. This is a realtive new infrastructe within mesa to allow "batch buffers". This means that all 3D stuff from userspace (i.e. glxgears) is packed into so called buffer objects and sumbitted in a batch to the graphics hardware (through the DRM). This has an obvious advantage: Less context switches from usermode to kernelmode. I guess there are even more advantages but I don't know the exact details.

airlied started working on this topic about a month ago and has done some major work. He did this during some major restructuring for KMS he was primarly working on. His tree also contains the latest changes jglisse outlined how to do better command submission. Lately ajaxxx picked up his work and has been working on it behind the scenes.

This weekend Nicolai Hähnle started his own approach on how to get the r300 driver into the direction of dri_bufmgr. He encapsulated the current method within macros that can be exchanged to a dri_bufmgr at a later point. He also implemented the dri_bufmgr interface from mesa. This obviously lead to a discussion with Dave Airlie since both work on the same area. It was agreed that the code should wait until Mesa 7.1 was released (which should happen soon) before any work will be done on master. Dave Airlie also suggested to base the work on Nicolai's code instead of his own. Now the code landed in a branch named r300-bufmgr in the main mesa git repository. So now everyone will (hopefully) work on the same code.

Let's look forward on what our wonderful open source radeon developers will do.

Update
Nicolai Hähnle explained the reason for dri_bufmgr.


The dri_bufmgr interface is essentially an abstraction for graphics memory management (and some related issues). Therefore, using dri_bufmgr in the 3D driver is a first step towards using a real, kernel-supported memory manager for graphics memory (i.e. GEM).

This is important for any number of reasons, but personally I am interested in supporting render-to-texture efficiently (whether via CopyTexSubImage or EXT_framebuffer_object). Render-to-texture is vital for advanced effects such as bloom.

Right now, when our driver uploads a texture into the graphics card's memory, this texture may be overwritten at essentially any time by another process once a context switch occurs. This makes it impossible to implement things like CopyTexSubImage and EXT_framebuffer_object efficiently in hardware.