I'll try and post these regularly when I make major additions/removals.

drm-radeon-testing is the cutting edge KMS radeon branch, it is going to be rebased and things will be added/removed as they are worked on by developers. So you can base patches on it but you should talk to the developer who owns the area first.

git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-radeon-testing

I've just pushed a rebased tree now with the following:

latest i2c algo + hw i2c engine code + all fixes squashed: This adds support for hw i2c engines found on radeons and
exposes them + sw i2c buses to userspace so i2c tools can use them. (agd5f).

pll algorithm reworking + quirks: cleans up the code to allow for the selection of the old pll algorithm on some hardware. (agd5f)

pm support so far: Adds all the current PM patches - just does engine reclocking so far using the power tables from the BIOS. (Zajec/agd5f)

Evergreen (Radeon HD 5xxx) support: basic KMS support for the evergreen range of devices - no irqs or accel yet. (agd5f)

radeon unlocked ioctl support (airlied)

bad CS recording (glisse)

misc cleanups/fixes - Dell/Sun server support ported from userspace hopefully.

The tree did contain Jerome's r600 CS checker but I've dropped it for now at his request as he has newer patches
in testing.

Here's a really badly shot video of GPU switching in action ;-0 - whiteouts are mostly be logging out and in ;-)

v6 of the patch + another patch which needs some work before I can merge it are available now.

This mainly cleans up the patch architecture a lot and allow for Matthew to put his nvidia code in easier hopefully. Its moves the ATPX specific code to the radeon driver.

The second patch is from an experiment that I videod on a webcam but am now failing to upload, I'll probably get a better video tomorrow, the lighting was fairly bad for it today.

It basically allows for a delayed gpu switch ( it changes the debugfs API ), and allows gpu drivers to block the switch.

The switch file now takes ON/OFF like always, but the PCI IDs input is gone. There are 4 commands

IGD - try and switch now to the integrated device - can fail if drm drivers block it (mainly if X has the device open)
DIS - try and switch now to the discrete device - can fail if drm drivers block it (X again).
DIGD - try a delayed switch to integrated device
DDIS - try a delayed switch to discrete device.

So with X running you can echo DDIS to the file and log off X, it'll then switch as soon as X closes the drm device, and when
gdm restarts X it'll be running on the discrete GPU. If we had a shiny GUI on top of this it'd be as close as MacOSX can do it.
When you select to do a delayed switch we power up the other GPU straight away so the switch is quicker.

It needs more debugging, some open issues include:

after a few switches it can die on its ass
powering up the Intel glitches the display even when running the AMD
there may be race conditions in the patch, probably need a mutex around device open + this stuff
suspend/resume - since we D3 the card, if you do an s/r cycle it'll resume it, we need a flag in the
driver to say its powered off by the mux and to ignore s/r cycles - I've started adding this to radeon.

mjg59 has access to an nvidia laptop and is looking closely at how to make that all work.

Okay v4 of the patch is available at

http://people.freedesktop.org/~airlied/vgaswitcheroo/
http://people.freedesktop.org/~airlied/vgaswitcheroo/0001-vga_switcheroo-initial-implementation-v4.patch

First thing I added was power up/down methods. This calls the DRM suspend/resume methods + along with the cut power for discrete GPU. I'm not sure dynamic Windows ever does this as it seems to take a bit of work, I suspect they just run the second GPU in really low power modes. This is slow because we have to repost the ATI card after turning it back on.

I then talked to mjg59 and worked over the ATPX detection. I removed all the DMI code and it should detect *any* laptop that uses ATPX (i.e. ATI/ATI and Intel/ATI) from what I can see. I've tested on Lenovo W500 and T500 now and it appears to work on both. Would be nice if someone on a ATI/ATI and/or ASUS ATI/ATI or ATI/Intel machines could give it a whirl. I think the main problem with ATI/ATI is the poweroff methods have a hardcoded Intel PCI ID. I've no idea yet how to tell on an ATI/ATI which device is the IGD and which is discrete. Its probably more than likely the IGD is the one with the ATPX method on it.

It doesn't switch off at boot yet but I've added commands to let you do it.

echo "OFF" > switch - turns off the not in use card, so if Intel and ATI are on at boot, it will turn off ATI
echo "ON" > switch - turns back on not in use card
echo "PCIID" > switch - causes a switch with full off/on cycles.

nvidia combos appear to use a DSM method and in theory nouveau_acpi.c should be detecting that, so it might be possible for someone to hook that up.

I've also started looking at some desktop integration via gdm or logout - but its not my usual place to code so going is a bit slower ;-)

So someone thought it would be a good idea to make laptops with two graphics chips in them and switch betweem them to save power.

Now other OSes support this to varying degrees, I think XP + MacOSX require a logout cycle and Vista/Win7 can dynamically switch while running, while Linux basically falls over in a heap.

So I sat down today with a Lenovo W500 which has an Intel GM45 and AMD Radeon 3650 Mobility in it, and I wrote a patch to try and get closer to the XP/MacOSX level.

The result of one days straight hacking is at:
http://people.freedesktop.org/~airlied/vgaswitcheroo/

The patch is totally focused on the Lenovo W500, other switchers will need to add stuff to this codebase.

So what works?
Boot in switchable graphics - which boots with intel and radeon turned on
KMS drivers load for radeon and intel, radeon BIOS stored in start of VRAM (driver hacked to read it)
bind to both drivers + fbs for both.
mount debugfs - cat /sys/kernel/debug/vgaswitcheroo/switch
2
0 :0000:01:00.0
1+:0000:00:02.0
shows the 02.0 (intel) device is in charge of the MUX.
goto runlevel 5, play with X under the Intel driver, goto runlevel 3 kill X
at fbcon echo "0000:01:00.0" > /sys/kernel/debug/vgaswitcheroo/switch
barely glitches console and switches
goto runlevel 5, play with X under the ATI driver, goto runlevel 3 kill X
echo "0000:00:02.0" > /sys/kernel/debug/vgaswitcheroo/switch
goto runlevel 5, play with X under intel again.
wash and repeat.

What does it do?
So far its just switching the MUX using the ACPI method and remapping all the console to the other framebuffer device,
it also reset the bits that denotes which devices is the boot vga device which X uses to pick the primary GPU. This
means X doesn't need an xorg.conf to switch. (I think all those patches are in upstream X server).

What does it not do?
It doesn't powerdown the radeon when its not in use yet. I know the ACPI call to power it off/on, and since I have
the BIOS I should be able to repost it. So I'll try adding the callbacks into the KMS driver to do this soon.
It doesn't poewrdown the intel when its not in use yet. Not sure what I can do here, since there is no ACPI method to turn
it off. I think I can just D3 the GPU, and use the normal s/r paths to bring it back. Again requires more investigation.
The whole what ACPI + methods map to what device, how the mux ids match etc will probably all need to be stored in the DMI table.
Anything not a Lenovo W500 - probably not that hard to add other Intel/AMD variants to this, add DMI and mux switching method.
nouveau isn't hooked up - this could probably be done by some interested party - the driver hooks so far aren't very hard.
No idea about ATI/ATI or NV/NV ones either.

I'm really hoping interested community people can make this actually useful to them on other hw, I won't have permanent access to the W500 to keep this all tested in the future.

Can we do dynamic switch without restarting X?
No. X needs a lot of work, a lot more than the day it took to hack the kernel.

How do we go forward?
We probably need to add gdm support to move this forward. A logout button that is "Switch GPU", that gdm kills the X server,
then hits the switch port and starts a new X server. I'll try and talk to some gdm hackers over the next few days.
I'll try and push this into a git tree against Linus current, and we can add tested patches for other machines as they go in.
Also the DMI section is only imaginary of what I think others might need, we might have to rip it all out. Also I've no idea
if there are ACPI methods to query the switchable modes etc.

So I originally was going to attend LCA 2010 for the week, but real life interjected and I couldn't abandon family commitments for that long, so I ended up doing a crazy cross-Tasman dash. As well as the change in flights, Isabel came down with a virus and Gia also got it, I think I got a milder version of it, but they both seem alright by the time I left but I had little sleep the previous two nights.

So I flew on Wednesday morning, got in Wed afternoon, met up with ppl, had a couple of beers, wrote slides, slept, finished slides, went to Thur morning, drugged myself up on Nurofen Plus to combat viral effects, gave my talk, went to see ajax talk, went to professional network dinner, went for beers with ajax + benh (listening to an American and a Frenchman speaking about wine while listening to drum n bass in a Wellington pub was a bit wierd). Decided to push on through, so got back to room at 3am or so, checked out/left for airport at 4:20am, flew at 6:20am, into BNE at 7am, home, bed, sleep for a few hours and mind Isabel for afternoon.

So my talk was "So you've put kernel graphics drivers in the kernel... what next? can I haz ponies?". My slide deck is off the 0-content style + lots of pictures of various ponies, which I've found, they'll be on the LCA site soon and I'll upload them when I plug that laptop in again.

(a) stop people reading ahead of your bullet points so they don't doze off while you are catching up
(b) gives them something to look at apart from me while they actually have to listen to me :-P

It seemed well received, the room was pretty packed out (ppl standing/sitting - LCA schedulers you listening?) and I don't think the sickness or lack of decent preparation made a big difference. I'd like to apologise for not even mentioning SGX/poulsbo, I'm not sure how but it totally slipped my mind, but the situation hasn't really changed in terms of how screwed it is.

I've just done a 1.6.0 release of radeontool from my personal repo, it contains both
radeontool and avivotool, and is probably full of ugly but whats in distros now is older
and worse.

radeontool (and avivotool) are lowlevel tools to tweak register and dump state on radeon
GPUs, they also can parse parts of the BIOS data tables.

Tarballs are at
http://people.freedesktop.org/~airlied/radeontool/

git://people.freedesktop.org/~airlied/radeontool.git

So the attendee's gift at Kernel Summit this year was an Intel X-25M 80G SSD. However as they had only just launched while we were at Kernel Summit, Intel couldn't get supplies to give them away.

So I a package today and lo and behold its got my SSD in it!!

So I've no real idea what I'm going to do with it, I have no laptop useful enough to support such a thing, so I've put it
into my desktop in the office for now. I suppose I can migrate all my git trees to it.

Any suggestions for what I should store on it? time for a new laptop sometime next year I suppose :-)

[update- lots of sugggestions to use it for my root partition, however my desktop machine boots rarely and has 6GB
of RAM, so it keeps gcc/firefox/openoffice in cache most of the time. So I suspect I really should use it for
my git trees where I spend a lot of time checking out and merging trees]

So just as an aside to radeon stuff, I spent an hour or two today on a break playing with qemu's vmware gfx + VMware's new vmwgfx kms driver.

I've managed to get it as far as showing me the console which was good,

http://people.freedesktop.org/~airlied/scratch/vmwgfx-qemu-hacks.patch

is the hacks against git://git.freedesktop.org/git/mesa/vmwgfx.git

the first hack looks like a bug in qemu, really it should expose a second PCI bar with the FIFO in it according to the VMware SVGA specification.

the second looks like a possible bug in vmwgfx if no irq is advertised from the device, which in this case there isn't,
vmwgfx gets a capability bit for having an IRQ from what I can see.

third looks like it should be necessary, but I'd need to read the vmware svga spec a bit more, without it, we get the
wrong fb size.

the fourth looks like a bug in qemu confusing depth and bpp, bpp can be 32, but depth is generally 24.

I'm not sure what I'll be doing further on it, it was just a neat afternoon hack I meant to try for a while

So Phoronix pointed out we have a KMS/DRI2 3D regression vs UMS/DRI1, two things sprang to mind wrt to places we lost some of this so I did a quick benchmark on my laptop.

Thinkpad T60P, rv530 FireGL V5200, Intel Core Duo T2500 CPU 2Ghz, 1600x1200 LCD

F-12 mostly.

So I ran openarena with Eric Anholt demo at 1400x1050 (not fullscreen)

5 tests, non-kms, kms out of the box, kms with color tiling, kms with vsync remove, kms with vsync removed + colortiling

non-kms: 840 frames 25.3 seconds 33.2 fps 9.0/30.2/55.0/6.7 ms
kms-nontiled: 840 frames 38.2 seconds 22.0 fps 9.0/45.5/81.0/9.4 ms
kms-tiling: 840 frames 31.6 seconds 26.6 fps 19.0/37.6/72.0/7.2 ms
kms-nontiled-novsync: 840 frames 35.7 seconds 23.5 fps 15.0/42.5/77.0/8.9 ms
kms-tiled-novsync: 840 frames 28.7 seconds 29.2 fps 11.0/34.2/66.0/7.6 ms

So there is some explaination of where some of the performance went, I'll definitely enable KMS tiling on r300->r500 where
we should have enough stuff in mesa to deal with all the sw fallbacks (gallium may need some work). The vsync vs non-vsync thing isn't something I really want to change, basically when DRI2 does the back->front copy it doesn't do it when the scanout is in the area being copied so with DRI1 you'd get tearing, with dri2 you get none. We'll also get DRI2 page flipping support at some point, which for a fullscreen app should really improve things. Besides that I'm sure there is lot of optimisation that can be done in the KMS codebase to improve this situation. I (or someone else please feel free) need to break out the profiling tools (perf, sysprof etc) and track down where we can do better.

At the moment the priority is still to make things work first, then make them fast.

Finally got some time to take another look at radeon displayport support.

I wrote initial userspace modesetting patches in June to get EDID and by mid July I had it to the stage where I could
get a display if I started X, then used xrandr to switch to a different mode. I ran out of time to continue investigations then.

Last week Alex Deucher rebased my code into the latest DDX and cleaned up a lot of the insanity in it. At the same time I started porting the code to the kernel for KMS support. Alex also picked that up and made the userspace and kernel drivers pretty much act the same. However at the end of this neither of us actually had reliable display port support.

So this morning I discovered that actually every second modeset was working, with ones in between turning off power to the monitor, so I moved a few things around in the displayport link training initialisation code and voila reliable userspace displayport. I then ported the same fix to the kernel and it didn't make it work. Another 2-3 hours of guessing found a missing
return statement which meant we ended up with a version 0 DP identification which broke stuff. With that fixed, KMS displayport started working.

Where can I get this?
UMS/DDX: git://git.freedesktop.org/git/xorg/driver/xf86-video-ati displayport branch
KMS: git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-radeon-dp branch

TODO:
a) When r600 grows IRQ support we need to use the hotplug irq to detect the monitor appearing/disappearing
so we can retrain the link with it, otherwise unplugging the monitor means it won't be there on replug,
unless you change modes, for userspace we probably need to use a timer to detect if the monitor goes away or we lose
training.
b) cleanup code, maybe see what we can share with Intel.
c) merge, I'd say we can nearly merge the UMS code to master, and KMS can definitely go in the next merge window.

[updated for pedants].

So I (and other radeon developers) debug a lot of radeon problems, both locally and with people over irc/bugzilla, and I often am quite slow to deal with bugs that I can reproduce locally, its usually a last resort to do remote debugging and its unfortunate for people who have hw bugs that we can't reproduce locally.

So what prompted this post?
https://bugzilla.redhat.com/show_bug.cgi?id=527874
KMS:RV515:X1400 Thinkpad T60 resume fails

So first up, my local Thinkpad T60p with an rv530 always resumed fine, my local T42 with 7500 mostly works okay as well, so
there goes my local reproduction.

So Peng works for Red Hat in Beijing and the week before kernel summit I sat down on irc for most of two days with him running various tests. We tracked it down in that 2 days to the fact that his video RAM wasn't getting setup properly on resume. The NMI on resume let me track down that when the gpu accessed the ring, it generated an error on the PCI bus, this led to checking the contents of the PCIE gart table (with a detour through kernel vmap page handling). The PCIE gart table is in VRAM, and upon checking it on resume noticed when we copied it back into VRAM it was getting mangled. So we could deduce VRAM was broken.

I handed off to Jerome and he got traces of the BIOS posting using VBE and using ATOM (which we use in the kernel), Jerome ruled out different parts of the engines and we got reports of it working for some people when powered down for a long time or other randomness, and we were going back and forth with ideas on what might be going wrong, and had started thinking we should power off various parts of the hw before suspend, and the problem was due to inconsistent hw state on resume.

Peng happened to visit Brisbane for a Red Hat meeting this week and brought the T60, and this morning I swapped my laptop for his. First of all I tried to play by plugging in a VGA monitor, this produced another bug where the LVDS would die when starting KMS, so I fixed that quickly first. So the VGA screen was also corrupted, and VRAM wasn't enabled at all. Next I tested vbetool posting worked, also suspend/resume to corrupt, unload radeon, vbetool post and load radeon worked. Then I started testing with Jerome's userspace atom init tool, doing a s/r, unload radeon, atom post, load radeon also worked fine. This is where it started to make no sense, since Jeromes tool was doing the exact same thing as the kernel parser. I started by blaming the atom delay code in the kernel but that proved a dead end after an hour or two. Next thing I enabled the kernel atom debugging and all of a sudden it resumed fine. So it was a timing issue somewhere in atom parser running the init code.

So enabling debugging put enough of a delay between operations that something that wasn't working before now succeeds. I started bisecting the debug messages, I removed half the debugging at a time until after about 3 hrs I got it down to one printk happening between two atombios commands. The surrounding code was reading and writing one of the memory controller setup registers on the GPU, so it pointed to some register write not getting fully into the hw before we read it back and write it again later. I changed the atom code to do a read back before writing regs for certain operations and viola all resumed fine.

So this took the best part of 8 hours, I reckon if I'd been doing the same over irc with Peng it would have taken at least a month of back and forth on irc to figure it out. Having the hardware locally even for a day made it possible to track it down and figure it out so much quicker and efficently. So the bad news for anyone with bugs we can't reproduce locally is that we generally will fix any bugs we can locally first just from a efficiency point of view, since we can fix them so much quicker and faster.

I've pushed out the drm-next branch to

http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-next

A few highlights include:
firmware loading for r128/mga/radeon + radeon kms drivers. (for all the Debian fans).
Intel -next tree pulled in.
radeon r100/r200 kms command stream checking
radeon kms tv-out support
merged fb handling for all kms drivers
DMT timings + better HDMI EDID decoding
R600 3D support
R600 KMS support (under staging drivers along with radeon KMS).

along with numerous other patch.

The r600 3D support enables r600 3D without KMS.

The r600/r700 KMS support in that tree enables full 2D/3D/Xv accel + DRI2,
you need a master libdrm, master ati DDX and master mesa. Jerome and myself
at Red Hat have been working on this tag team along with Alex at AMD. It may
not be 100% stable yet and I'm sure we can make things a lot faster, but
the basics all work for me here. So get testing and reporting please.

Fedora rawhide users, just wait for a day and it should all be available.

I've done some boot testing on my rs780, rv635, rv610 and rv730 so far
and all seem to at least start and run my X session.

So X.org has long contain a layer known as RAC or Resource Access Control. This layers job was to arbitrate between multiple X.org drivers running inside a single server for access to shared resources. A resource is defined as an I/O region, MMIO region, FB region, VGA I/O, VGA FB apertures. Now back before we had operating systems that actually set hardware up properly, X used to do a lot of work. For example it pretty much tried to fully control the PCI bus, and was able to allocate resources to GPUs when the BIOS or OS didn't do so. It was able to dynamically switch on/off any resources a GPU could care to want.

This system was engineered with some really scary scenarios in mind, it could deal with sharing PCI decode space between two devices (something PCI can't really do). It could deal with setting up GPUs the OS hadn't assigned PCI resources to. It could share the limited x86 I/O ports between multiple cards. It could also do all the simple scenarios well.

Now back then maybe some of these things were necessary however nowadays really only two shared resources are left that we want
X drivers to care about. We hope the OS can assign all the PCI I/O space and PCI memory space so that X doesn't need to try and multiplex it.

Also this system has some major disadvantages, two X servers couldn't be used as the locking was all done inside one single server, so a second server would just race with the first. Graphics cards could never reliably use interrupts, since if you disable a cards MMIO region and it receives an interrupt, generally bad things will happen.

So fast forward to 2009, where we have pretty much OSes that do things correctly and we have only two shared resources we need to care about VGA i/o and VGA memory (0xa0000). Now the way VGA works on modern PCI systems, is there is a bit in each bridge which denotes whether that bridge routes the VGA decodes to its bus. On that bus there is allowed to be one device decoding VGA resources at any one time. The bridge forwarding is controlled by a bit in the bridge PCI config, the VGA decoding is controlled by the PCI COMMAND_IO and COMMAND_MEM bits. These bits however disable *all* IO and MEM accesses to the PCI device. Now most modern GPUs can disable the VGA decoding on its own, however this is GPU specific and there is no generic PCI config space bit to do this (FAILLL!!!!).

So the OS kernel needs to provide some sort of arbitration logic between processes wanting to access the VGA decodes. Reasons for wanting the VGA bits enabled for a GPU are generally doing any int10 call (like card posting or VBE mode setting), or doing console save/restore when X is starting/stopping. Some GPUs use the VGA i/os still for modesetting but these are generally very old cards. Some nasty ACPI/BIOS implementation also seem to like having VGA routed correctly for suspend/resume.

So Ben Herrenschmidt, Tiago Vignatti and myself brought the VGA arbiter into the world, the code has taken a couple of years to get the attention it needs to go upstream. The vga arbiter exposes a /dev/vga_arbiter node, that X can open and use to route the VGA io/mem decodes between any GPUs in the system. So how does this deal with the issues RAC had:

1. Multiple processes:
Since this is in the kernel, the lock is now available across processes so multiple X servers can in fact fight over the VGA.

2. Interrupt handling:
Since most of the IRQ handling for GPU devices is done in the DRM layer, the arbiter allows a callback to be registered for devices which cannot disable VGA decodes on-card, so that they can disable their irqs when their memory/io decodes are turned off.

3. Cards with local ability to disable VGA mem/io
Cards can register that they can disable VGA mem/io locally. This means these cards are removed from VGA arbitration completely. Generally for this to occur a KMS or other proper kernel driver is preferred. Since if X decides a card doesn't need arbitration another process might decide it does, so having a master kernel driver that owns the hw makes this a lot easier.

4. Crazy ACPI cards.
The arbiter does nothing if only a single card is registered with it. So it will leave the VGA decodes enabled on all single GPU systems. If a GPU was hotplugged, the driver will get a callback saying it needs to disable VGA decoding on itself. Generally we won't see the crazy ACPI issue on multi-gpu systems.

However there is one issue we are seeing with the VGA arbiter that RAC never really addressed either, interaction with kernel DRI. So I suspect we will disable DRI access for any GPU that requires VGA routing. The issues I've seen so far are all contentions issues with the arbiter lock. They can probably be worked around on a case by case basis, but really just get KMS already.

So we are hoping to upstream the kernel code for 2.6.32 and push the libpciaccess and X.org server patches to their master repos
around the time the patch is in the pci queue.

I'm sure I've missed something as I've been working on this for 4 days now, though I lost a day going in a redesign loop :-)

So we've had an -ati DDX with KMS support in a branch for quite a while, but it was starting to grow into a very big mess, and some of the hacks in it were quite unmaintainable.

So started cleaning it up and pushing the bits to master.

Step 1 was adding macros in all the places in the accel code to abstract away the different command submission methods, and
add some ifs to do KMS specific things. Once this was done in theory the accel code wouldn't functionally regress and wouldn't require any more changes.

Step 2 was bringing over the kms and DRI2 support files from the branch.

Step 3 was making the decision between if (kms) if (!kms) blocks all over radeon_driver.c in all the various functions or having a nearly completely separate KMS/DRI2 driver file. The original code has the if approach and it was an unmaintainable nightmare, so I opted for approach 2 and it definitely is the best. At driver probe time in radeon_probe.c, I now do the KMS check if the pciaccess probe is called (kms without pciaccess is probably not going to matter). If I get KMS supported the driver picks a nearly completely different set of functions for PreInit/ScreenInit etc. I now have a separate radeon_kms.c file which has all the DDX interface in it. Of course if we have any changes they may need to be done in two places, but its a lot cleaner than it was in the other codebase.

I also ported the KMS code to use the libdrm_radeon buffer management code which is shared with mesa, instead of the DDX having its own buffer manager code base. This code is well tested via mesa, however it hasn't got all the features/optimisations that I've added to the DDX bufmgr over the last while.

So what's left:
Missing optimisation from old buffer manager:
1. buffer in VRAM? has the buffer ever explicitly been validated to VRAM, this allow for an optimisation on download from screen.
2. Download from screen, with driver pixmaps we don't know if the buffer is in VRAM or GTT, with (1) we can either blit if in VRAM, or just memcpy if in GART.
3. force a buffer to validate in GTT or force a buffer to stay in fast CPU access space - this was really useful some sw fallbacks where a buffer would end up in VRAM and then get used by the CPU from there. It probably only really takes the place of fixing EXA properly so the pixmap scoring is separate from the offscreen memory, and having a XA that works with driver pixmaps a lot better.
4. bugs and crashes I appear to be hitting a realloc crash at some point where glibc reenters itself and fails.

So there is a kernel conference on in Brisbane next month, being run by Sun.

Now when this was announced initially it was proposed as an all kernel hackery type get together for folks in the region, not matter which kernel they cared about.

(I did propose to talk about kernel graphics at this and got refused - so maybe I'm just being bitchy, however this is my blog).

20 speakers break down as follow:
12 Sun
1 Intel - Sun manager
1 RH
1 OpenBSD
1 FreeBSD
4 misc.

2 of the misc talks are in some way OSOL related,

the OpenBSD talk is about networking and pf, the RH talk is about security, FreeBSD about storage.

Now really if you aren't into OSOL or ZFS (3 slots OSOL FS related), why would you go. This conference is
local to me and I still couldn't justify paying the signup fee/taking the time to my manager at all. Now if
one of the main kernel and X.org hackers who lives in Brisbane can't be bothered to go, I do wonder
why anyone who isn't into OSOL kernels might be tempted.

There was talk of a .au unconference at one point, which maybe when the whole swine flu escapade is over might
actually be a useful meetup for the aussie open source community.

Okay radeon TTM/KMS has landed in Linus tree under staging.

To enable it you need to enable CONFIG_DRM_RADEON_KMS, which relies on CONFIG_STAGING being set.

please read the CONFIG_STAGING warnings, esp the
"Please note that these drivers are under heavy
development, may or may not work, and may contain userspace
interfaces that most likely will be changed in the near
future."

Now to get a userspace that can use this code you need to get

git://git.freedesktop.org/git/mesa/libdrm master branch
and build it with --enable-radeon-experimental-api and install that.

git://git.freedesktop.org/git/xorg/driver/xf86-video-ati kms-support branch
build that second

git://git.freedesktop.org/git/mesa/mesa.git master branch
build this with libdrm_radeon somewhere that pkgconfig can find it.

You should either have KMS + DRI2, or a pile of smoking trash.

Please report any mode type issues on #radeon or dri-devel mailing list.

If you can't compile or configure your system to use this please wait until you have a distro do it for you.

If you are using Fedora 11, grab the latest xf86-video-ati from koji and all you need is the new kernel bits.

Known issues:
My DDX reports something about DRM 2.0.0 and wanting 1.2.x or something like that, you messed up setting up the DDX or are
still using the system DDX.
Xv might be broken on resize (or normally)
r600/r700 doesn't work (no surprise its not ready yet)

So I merged the rewrite of the radeon/r200/r300 to the mesa master today.

On a non-KMS DRI1 system we are hoping these patches are mostly regression free in terms of lockups and possibly fix a fair few lockups thanks to Maciej and Jerome's work.

Of course on a KMS/DRI2 system, this work enables GL on r100-r500 families of radeon cards and we hope to add more features to the ones we gain. We should now at least have FBOs where we never did before (in DRI2/KMS mode).

R600 work is ongoing in a branch still so this announcement has no effect on r600 or above.

I've also sent Linus a drm pull request with all of Intels drm-intel-next branch + all the patches I had sitting in my queue.

Early next week I'll send him the KMS patches for radeon, which will be in the radeon driver but the enable switch will be hidden in staging, while we stabilise it, since its such a huge amount of code. So don't expect miracles out of it anytime soon.

On a PCI ID table comparison Intel KMS have 28 IDs to support, radeon KMS has ~350, granted this code has no memory manager for r600 and up yet (kms code sohuld all be there), so its probably close to 200 GPU variants (+/- 50 for ids not seen in the wild maybe).

So Gia, Isabel and I are off to Ireland for 3 weeks from the 7th -> 31st of May.

Radeon KMS is all I've been doing lately and my feeling is the F11 driver is in a fairly good state, a lot better than F10. 3D seems to be working okay, however we have some speed regressions that I will be attempting to track down in earnest on my return. AGP cards got hit a bit lately as a fix for a real bug slowed an optimisation I previously made down.

For mesa I'd really like to merge radeon-rewrite to master already, but I expect I should wait until I get back as I need to be more reactive to fixing regressions in it.

So I've been slowly getting radeon-rewrite into a useful state, I diverted myself on Friday evening to take a quick look at FBOs on KMS/DRI2. I'd already layed down most of the basis for FBO code so I thought it might not take too long to get working.

So today I merged the FBO code into the radeon-rewrite branch, its not perfect but its a good place to start, its only enabled for KMS/DRI2 setups of course.

So there are a few things left to get radeon-rewrite into master:

1. Fix hangs on r100/r200 that some people have reported. I'm not having a huge amount of success in reproducing this, but I'll try and give it a larger effort asap. Its hanging in the buffer manager aging code somewhere. It smells like a GPU hang but its hasn't actually hung, killing the app, and starting it again, keeps things going.

2. r200 depth buffer is broken.

3. DRI2 single buffered rendering isn't drawing to the window where it should.

4. Have to run piglit regression tests on r100/r200/r300/r400/r500, under current mesa master, radeon-rewrite, radeon-rewrite DRI2 with swtcl and hwtcl paths. So I think it works out around 30 tests cases to try, and then fixup the regressions!!

5. lots of other things I've forgotten.

Post merging, I need to add support for two things back:
1. Color buffer tiling under KMS/DRI2. Works fine under DRI1.
2. Texture tiling under *.