airlied

radeon DDX has initial KMS support

Thu, 02 Jul 2009 06:09:20 GMT

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.

Kernel Conf Australia - ! all OSOL honest.

Mon, 29 Jun 2009 07:37:38 GMT

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.

Initial KMS support for radeons merged to Linus tree.

Wed, 17 Jun 2009 08:15:44 GMT

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)

radeon-rewrite merged to mesa master + drm pull

Fri, 12 Jun 2009 06:44:00 GMT

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).

off on holidays

Tue, 05 May 2009 11:16:45 GMT

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.

radeon mesa drivers status + FBOs

Mon, 23 Mar 2009 09:49:47 GMT

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 *.

clean design and abstractions

Sun, 22 Mar 2009 12:30:15 GMT

previous quote by radeonhd devloper: "And this is real cutting edge stuff, we're doing things no-one else is doing"

mailing list today:
"A question the for the radeonhd developers: Why are you not using the register access routines provided in compiler.h for the purpose? By not using those you break portability."

These two things may not be equal.

radeon 3d drivers merge plans

Thu, 12 Feb 2009 08:40:30 GMT

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.

Oh I forgot to mention the best bit:
100 files changed, 11289 insertions(+), 15487 deletions(-)

4000-5000 less lines of code ftw. I have a few more license headers in new files :)

Life at RH update.

Fri, 09 Jan 2009 01:30:25 GMT

(meant to post this pre-baby)

When I originally started to work for Red Hat I relocated to Brisbane so I could be based in an office and for other personal reasons. I was the first kernel/X.org/OS engineer based in the Brisbane office and the rest of the X.org team was based in Westford, MA mostly. I didn't think at the time this would change much, I mainly wanted to have the office as an option to work in as I can get demotivated working from home, changing scenery helps.

When RH moved offices in Brisbane last year, a new lab was built in the new office, and I got assigned a nice desk + rack + remote power + remote KVM over IP. This has proven really useful for doing development on all my different machines.

So mid-last year RH desktop team got the opportunity to hire Peter Hutterer who was based in Adelaide at the time, and we persuaded him to relocate to Brisbane once he finished a few things in Adelaide. He finally relocated a couple of months ago and is hacking lots on getting X.org input to a better place.

Late last year we also had a replacement position open up in the X group, and after some searching, Ben Skeggs, one of the top two nouveau developers (nvidia reverse engineering project) was interviewed and accepted the position. Ben was based in Tasmania, and agreed to relocate to Brisbane and started this week in the office. Hopefully this will mean good things for Fedora + nouveau development.

Its nice to have a team in one place for a few reasons,
a) people to talk technical to in the same timezone!!
b) easier to keep a hw library in one place, since we mainly do hardware enablement on Intel/AMD/nvidia hw having access to as many cards/systems as possible in one place very winning. With having more people in the office we can work on getting more hw directly shipped here and build up a better development environment.
c) talking technical can involve drinking.
d) easier to attract more people to the sunniest place to work :)

blast from the past - dog bites man.

Fri, 09 Jan 2009 00:22:00 GMT

update from between the baby naps :)

So back in 2002 while trekking in Nepal I got a dog bite from a possibly rabid dog, hilarity ensued (well actually scaryness), recently the story got picked up again by an Irish medical communications company, and has now appeared in the Irish Evening Herald and Longford Leader with at least one other paper possibly running an article.

http://www.herald.ie/national-news/city-news/warning-after---irish-trekker-in-rabies-ordeal-1587917.html
http://www.longfordleader.ie/news/Longford-man-relives-rabies-horror.4848488.jp

update: rapid->rabid :-)

Isabel Airlie.

Thu, 01 Jan 2009 12:13:03 GMT

Isabel was delivered this morning, at 11:54am, at 8lb13oz (4.07kg).

I'll be slow on anything non-baby related for a while :)

AMD release r600/r700 code

Mon, 29 Dec 2008 22:13:25 GMT

AMD today pushed the initial code to support acceleration on the r600/r700 range of GPUs.

This consists of r6xx-r7xx-support branches in the drm, radeonhd and a new r600_demo repo.

This code is really only for developers at this point but its great to see AMD finally get things lined up to allow this code to be released.

I've only been barely involved in the r600 code so far, I wrote the original drm over a few days and handed it over to AMD to continue on with, as I wanted to concentrate on the kms work. Hopefully I can get some time to look at it over the next while (yeah right, new baby still not here).

Kernel modesetting pull request sent

Mon, 29 Dec 2008 09:17:54 GMT

So I sent a drm pull request that includes the kernel modesetting core + intel i915 driver supporting it.

This is a major milestone for a project I started working on in a previous job, and I barely remember burning through the initial code for the initial prototype in a week of little sleep.

To enable the code you need to set the CONFIG_DRM_I915_KMS, this isn't enabled by default, as we don't have a userspace that supports it available yet for general consumption. If you enable kms now, you will more than likely get a broken X for your trouble as the kernel drivers aren't compatible with having userspace drivers trample the hardware.

So where is ATI at?

although we are shipping radeon code in F10, the code is based on the TTM memory manager, which isn't really in an upstreamable
state in its current form. Hopefully a newer TTM codebase might become available that can be used upstream. If that doesn't happen, we might rearchitect the core memory manager code of the radeon system now that we have the API mostly proven. So I'm not sure when we will upstream it, it all depends on how much time I can work on it.

Baby status: due today, no sign yet, will severely impact amount of time I spend on this stuff :)

r500/600 tv-out merged but needs enabling

Mon, 22 Dec 2008 20:39:23 GMT

So we merged r500/r600 via atombios TV-out support, but we haven't enabled it by default.

You need to add

Option "ATOMTvOut" "true" to xorg.conf to enable it.

We'll hopefully get to fix up some of the remaining corner cases and issues or enable it at
least on a card by card basis.

radeon r500/r600 tv-out + atombios

Wed, 17 Dec 2008 05:31:31 GMT

Okay I've just spent a few days doing output enablement on -ati, since I got an rv730. I decided to try and get tv-out up and going again.

I've pushed a branch to the main xf86-video-ati repo called "atom-tvout"

Please test this on any r500 -> rv7xx cards if you are interested in TV-out support on this range in open source drivers.

It mostly uses atombios to set the cards up, with one exception for the scaler on the R500 cards which I'm discussing with ATI.

I've also added and tested DCE3.2 output support to master in the past day or two, I just need to add the official PCI IDs for all the rv7xx variants.

cool radeon enhancements...

Fri, 05 Dec 2008 09:16:30 GMT

As Alex mentioned http://www.botchco.com/agd5f/?p=33 the radeon community developers have been tearing *pardon the pun* along making radeon do cool things on top of the cool things it already does!!

Alex came up with an idea a while back to try and get tear free EXA and Xv rendering. Tear free Xv means we hopefully can get textured video on (r100->r500) without ugly tears in the middle. Pierre Ossman took on the proof-of-concept Alex hacked together and spent some time making it all work properly. While he was there he picked up the r3xx/r4xx bicubic shader two of the other developers (Maciej and Corbin) had started but never had time to finish debugging, and pushed it forward so it works on those chips.

Its always good to know there are developers out there scratching itches and that with a small bit of input from Alex or myself can push the project to do what they want. There have been many accusations levelled at the radeon codebase over the years but the number of really useful community contributions has risen a lot lately, so it can't all be bad!!

So if you want tearfree Xv video on your r300/r400/r500, radeon is now the only driver that can provide it.

No we don't have any r600 support for Xv yet, stay tuned hopefully :)

KMS and AGP r300s

Sun, 30 Nov 2008 08:54:53 GMT

Okay I'm hoping I've found the bug that was causing KMS + r300 AGP systems to be so buggy.

I've just found a couple of bugs in the AGP codebase that might mean I can reenable AGP mode by default
instead of the PCI fallbacks. you can try radeon.agpmode= 1,2,4,8 to enable AGP speeds, or -1 to fallback.

I've just kicked kernel-2.6.27.7-132.fc10 into koji so it might help a few people.

Also AGP r500/r600 cards are an abomination, they are just a PCIE chip with an AGP->PCIE bridge on them, the old
AGP fallback code used to hit PCI fallbacks but it should use PCIE codepaths on these chips by the looks of it.

So I've also fixed that.

EXA and kernel memory manager (the DFS saga).

Thu, 20 Nov 2008 05:50:48 GMT

So I've been going over the accel in my radeon EXA code particularly how we related to buffer management.

One thing I noticed, is I've implemented a really sub-optimal DFS.

DownloadFromScreen is meant to accelerate reading back pixmaps from offscreen. However with driver managed pixmaps, all pixmaps are
considered to be "offscreen". Now my great implementation, created two scratch buffers, and executed blit commands moving parts of the pixmap into each scratch and copying it into the supplied destination pointer.

However this sucks when you think about the use cases:

1. backing BO for the pixmap is actually in VRAM - not a bad solution
2. backing BO is actually in GTT and wasn't in VRAM - really crappy solution - we end up doing a load of GTT->GTT blits followed by memcpys.
3. backing BO never used in hw - worse we bind it to GTT, blit it, copy it.

So clearly I was delusioned when I wrote the initial implementation... however it lead me to wonder what the right answer is and where in the stack to effectively code it.

What we have now is EXA->driver->driver bufmgr->kernel layers. The buffer manager abstracts away the kernel internals and lets us just reference buffer objects in the driver code without worrying about where they are located. The bufmgr/kernel don't have any acceleration functionality, except the kernel has a fast buffer copy and buffer clear functionality, used for moving buffers around for eviction etc. So the problem is the driver bufmgr and above really don't know where a buffer object is currently located, the kernel only knows for certain. As objects may be evicted by the kernel on a whim or after a suspend/resume etc.

So ideally the driver would know that pixmap is in VRAM, I'll use the cool method, but if its in GTT or never in hw I'll just memcpy it and save the overhead of doing the other stuff. However since it doesn't know where the buffer is currently, it can't really do this. I'm suspecting I might need a kernel interface to optimally copy data to a userspace pointer from wherever the buffer is currently located, but that smacks of having more acceleration in the kernel, esp since DFS allows for rectangular blits. If for future cards like r600 I don't have a 2D engine to do this with, I don't really want a load of 3D engine in the kernel.

So for now I think I'll just pull more of my hair out.

lessons learned writing a kernel memory managed driver

Wed, 19 Nov 2008 05:32:42 GMT

1. whatever corner case you never expect could ever happen - it will 5 secs after release (this is a generic sw lesson)

2. X does rendering without the vtSema, including hw calls. So if you invalidate the 3D state flags in EnterVT its too late, X has already sent command to the card without resending the state. So invalidate your state in LeaveVT as well.

3. Kernel memory management is a messy problem. The GPU has a finite amount of addressable memory it can use. On modern GPUs, this is either a single GART (like Intel) or VRAM + GART (like everyone else). So userspace applications like X or 3D apps, submit command buffers to the kernel, and along with a single command buffer there is a list of referenced data buffers. These data buffers can be pixmaps src/dst/mask, textures, vbos, fbos whateva. The userspace gives the kernel this list along with acceptable placement parameters. (GEM API uses a set of read domains, and a single write domain). If the buffer is to be written to it needs to end up in the write domain, for reading it might be acceptable in a few places. So on my radeon driver for example it is acceptable to read the buffer from either GART or VRAM, but only write to VRAM buffers. So when the kernel gets this list of buffers it tries to fit them in as well as it can. Now if the kernel can't fit these buffers in, we are in a bind. The naive person would just say fallback to software, and I spit on them. Because building the command buffers happens over time, the operation list and codepaths that generated the command stream have all been done. So we can't just go back and redo the operations in software fallbacks. So we run into the problem that userspace cannot reference more buffers in the command stream than the kernel can relocate into memory at once.

Rule 1: The kernel cannot fail to complete the command stream under any circumstances.

The two ways around this - are insert places in the command stream where its legal to break it up or have userspace flush the command stream when it hits a limit on the buffers.

For radeon I've done the latter. At startup the kernel tells X the amount of dynamic VRAM and GART it has to play with.

Then before each operation in the 2D driver, I sum up all the buffers it references for read and write, and then compare the write with the amount of VRAM and read with the amount of GART. If a single operation cannot fit at all in VRAM/GART, then sw fallback it. If the current op + total of ops in the list doesn't fit, flush before the current op and try again.

Now this works up until it falls over in a heap.

Why? Well firstly if a buffer was just written to in a previous cycle, it will be in VRAM, however X doesn't know or care where the buffer lives, so when it submits a read for it, it totals it against the GART read space, and when the kernel goes to fit everything in, it already has left that buffer in VRAM taking away from the write space. So to solve that I have the kernel do a two pass, it validates all the writeable buffers first (which if not enough space will kick out the readable buffer), the validates all the readable buffers (which will pull it back into the GART).

So this works great until it falls over in a heap.

So you submit the kernel a load of command streams over time, and VRAM gets a bit fragmented. So you have 20MB of dynamic VRAM,
you have 5MB of 1MB buffers, then 10MB free, then 5MB of 1MB buffers, you have 13MBs in 3 buffers (1MB, 1MB, 11MB), the two 1MB buffers are just before the 10MB and just after it. So the command stream validates those two buffers at those two points, then goes to validate the 11MB buffer, and goes all wtf? and it fails. See rule. 1.

Of course per-context GART tables ma
So now I needz defragmenation. Simple defragmentation is to kick out all the dynamic buffers from VRAM and revalidate them in order so they all fit in. Its messy but it should mean I get a system that doesn't violate Rule. 1.

Now I'll probably like to think about inserting scheduling points in the stream, but I'm not sure how well that wins, and whether I'd still have to worry about the fragmentation issue somehow.

Of course per-context GART tables and page table addressable VRAM makes all of this stuff a lot easier, or at least push the problem out to a lot harder to hit boundary, however see the first point I made.

So if you are ever in the enviable position of writing a kernel memory manager for a graphics card, allow me to buy you some spirits.

fixing bugs by accident ftw...

Sat, 01 Nov 2008 01:46:41 GMT

So we've had this bug on modesetting on radeon for a while where random strings of glyphs in a pixmap were getting corrupted when
scrolling in xchat or gnome-terminal or firefox etc... I've been looking into it on and off and keeping it in the back of my mind trying to figure out what could be causing it.

So I came into the office on Friday feeling a bit tired and decided to just go and do some random hacking on the radeon code that I'd contemplated for a while. Radeon GPUs have a memory controller which gives a 32-bit space to the GPU consumers, and in which you map the VRAM and GART. However access to the address space that fall outside the VRAM/GART mappings end up getting passed through to PCI DMA controller and accessing main memory at that address. One the PCI/AGP variants this feature cannot be disabled, however on the PCIE variants you can discard and error on accesses outside the GART/VRAM. I've wanted to enable this for a while but never found the time.

So I patched my kernel to enable it and straight away on starting X in kms, I got an NMI and the GART logged an error at address 0 being accessed for a read. This intrigued me as I was sure it wasn't on purpose. I added a bunch of debugging to track it down to a buffer migration into VRAM. Upon migrating an untouched buffer to VRAM I was doing a solid fill using the 2D engine to 0 the VRAM area. This is doing using a radeon type-3 CP packet called PAINT MULTI. (Its explained in the r500 accel docs). The fill operation of course is a destination fill so it shouldn't try to read from any source, and I wasn't specifying any source in the packet. However clearly it was reading from 0 which was causing the NMI to trigger. The packet format looked fine, and eventually I got to reading the ROP3. ROP3s are raster operations defined for 2D accel, mostly from the Windows GDI days (at least I use MSDN to get at the defines still.). The packet was set to ROP_S, which is a solid copy ROP, not the solid pattern ROP I wanted. Changing it to ROP_P gave me the solid pattern fill ROP and got rid of my NMI and X worked fine with the out of bounds checking enabled.

I then noticed that my transient glyph corruption had disappeared, as sometimes the source must have had data at 0 and it was introducing crap in to the VRAM instead of zeroing it. So it just goes to show sometimes slacking off and not trying to fix bugs is the best way to fix bugs!!

testing modesetting on radeon...

Sat, 06 Sep 2008 08:42:48 GMT

So if you are feeling like testing modesetting on radeon cards, here are some methods.

a) Install Fedora rawhide - remember nomodeset on the kernel commandline disables it.

b) get some repos.

You need to do a full kernel build for this stuff.

git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-rawhide
git://git.freedesktop.org/git/mesa/drm.git modesetting-gem
If you already have a kernel with GEM bits in it (i.e. rawhide or you have intel stuff - you can
pull this repo and build the kernel modules with make OS_HAS_GEM=1 radeon.o

git://people.freedesktop.org/~airlied/xf86-video-ati radeon-gem-cs
git://people.freedesktop.org/~airlied/mesa r300-bufmgr

If you don't care about 3D you can ignore the mesa tree. You need to build a kernel and choose the radeon drm,
and you can enable modesetting by default. You need to build libdrm from the modesetting-gem branch, and
you need to build the ati driver against it. 3D only works with r300->r500 and even there has some bugs. 2D X.org may not work with render accel on r100/r200 as I need to add a lot of commands to the verifier.

In theory rebooting into the kernel should give you modesetting.

So far the systems I've tested this on are:

PCIE:
RV530 FireGL in a Thinkpad T60P - LVDS + VGA
R580 X1900XTX - DVI + VGA
RS690 - VGA
RV370 in laptop - LVDS + VGA

PCI:
RN50 - vga - no render/3D
RV100 - tmds - no render/3D

AGP:
RV250 on SIS AGP - DVI (Internal/External TMDS) + VGA - no render/3D

So the two areas with problems most likely are AGP and LVDS. and I'm sure r420/rv410 will throw some curve balls as the usually do.

If you are using Rawhide and/or enable modesetting by default you can add the "nomodeset" to the kernel
command line to disable it.

To debug bootup hangs etc you can

1. boot with command line options "nomodeset 3"
2. rmmod radeon drm
3. modprobe drm debug=1
4. modprobe radeon modeset=1

see if you get an oops.. you can fire the dmesg off to me if you want as well, an Xorg.0.log from a working -ati
on the same machine may also help.

I'll hopefully get some radeontool tests available to find regressions.

encrypted rootfs vs suspend/resume

Thu, 21 Aug 2008 01:10:40 GMT

RANT MODE ON

So one of the things people have been wanting for a while is an encryted root filesystem.

Now this isn't some sort of security saviour and I was just chatting to a few people on irc and realised the pain we need to go through to actually make it secure and useable in the face of other things.

Scenario: You have a laptop, you want to "secure", you use an encrypted rootfs because the forums told you to. Now Linux suspend/resume support gets good enough that you don't ever reboot. So when the laptop is suspended where are they encryption keys?
oh they are in the RAM? oh thats nice. Even when the laptop is resumed, where are they? oh look a screensaver is stopping me from logging in.

Solution: remove enc keys on suspend - ask the user for them again on resume. - sounds easy.

How do we ask for the keys then?

Currently in Fedora we plan to ask for the keys in the initrd. This works fine if you are using an English based language and keyboard. What happens if you want to use some of your own language like Chinese. Oh you want input methods so you can type that in do you? Oh we need X. Oh lets put X in the initrd. Oh lets migrate lots of the supporting bits into the initrd. Hey wait a minute half my encrypted root is now in an unencrypted initrd. WELCOME TO DRINKIN' ISLAND!.

So maybe some sort of encrypted overlay on top of an unencrypted rootfs that can bring up enough X to type the password in might be a better plan in sane universe where different parts of the OS talk to each other.

RANT ENDS.

initial kms for radeon r500 atombios pushed

Fri, 25 Jul 2008 23:08:42 GMT

AMD today announced the source code to that atom parser from their kgrids project, I've been playing with this code for a few weeks to see if we could use it for kernel modesetting (kms).

So I've just pushed my initial radeon kms code to the "gem-modesetting" branch of the drm git tree.
The corresponding DDX code is in the radeon-gem-ms branch of my personal xf86-video-ati repo.

This contains 2 major things - and doesn't contain lots of other major things:

1. GEM style API to userspace layered on top of TTM internals.
- Only really does pinned allocations - no superioctl support yet, working with Jerome on tying that down.

2. atombios parser from AMD + modesetting code.
- This only support rs690 and r500 devices so far. We don't have r600 code in the drm tree properly yet,
and legacy bios is TODO.

So the major TODOs are:

add support for modesetting on legacy cards (r100/r200/r300/r400) - ported from -ati driver. We need a fixed point
implementation of the bandwidth calculation code.

proper command submission - Jerome is looking into this and I think we have a solid plan. for now I'm just abusing the old
style command submission routines with GEM ioctl.

3D - cmdbuf work on the Mesa drivers needed, RH has some in-progress code.

EXA pixmaps - still using one big EXA offscreen area, probably need to move to EXA pixmaps for DRI2 and also to use the superioctl properly.

gdbing the X server with xkb ... finally..

Fri, 25 Jul 2008 03:42:33 GMT

So for a long time if you ran X inside gdb, gdb would die badly when X forked xkbcomp. X hackers have worked around this by either running -kb or attaching gdb after X is started for many years.

I finally found it by accident this morning, I was working on some modesetting things, and had been gdb'ing the X server fine, when suddenly it started doing the wierd hang, I realised I'd just enabled direct rendering code and initialised the lock.

Now the kernel has this really really really really dirty hack for the DRM that I'm not 100% sure we really need anymore. The original drm designers decided that if a DRI client held the lock then if it died it might crash the GPU, so they got this special signal blocking code into the Linux kernel which we use to block certains signals across lock hold. When the lock drops, the process gets the signal. Of course one of these signals was one gdb was using to stop the X server and the X server always holds the lock when running so it got confused when an blockable signals somehow managed to block itself :)

Now the fixes for this are

a) kill the notifier stuff, I'm not sure it ever mattered, I at least could kill it for modesetting drivers as we have a lot more
control over the GPU from the kernel.
b) Have the X server drop the DRI lock around certain operations like xkb execing xkbcomp etc.. this seems worse.

What I've done for now in drm git is just not set the notifier up for the "master" process, i.e. the X server. This will at least allow people to debug their X servers with xkb.

technology fail weekender...

Sun, 20 Jul 2008 23:14:08 GMT

So this weekend was a total technology fail..

so on Sat night Gia rented a DVD to watch on a laptop, I was all should be no problem with this, armed with my livna (and livna-development) repositories, I started off on laptop 1, Thinkpad T60P. totem pulled an immeditate choke with some useless error message. mplayer choked similiarly with a nice bonghits in the libdvdread error message. This I tracked down to the region not being set correctly, so I set the drive region to region 4, and then mplayer failed even harder in a tight loop with kill -9 the only way out. It looked like bad sectors or something in the kernel.

So I went and tried it on laptop number 2, my Dell Insprion 6000, this machine is the oldest piece of kit I own and has been steadily on it way out the door (backlight flickers on/off due to dodgy connections internally). However it is also the only machine I have at home with a non-Linux OS on it, it has Windows XP. So I booted XP on it, stuck the disk in and it played fine, I then booted Linux on it and had the same problem as on the the other laptop. So I decided to let Gia use Windows XP to watch the DVD, I then unplugged the laptop before realising the battery was sitting on the bench (as it overheats a lot instead of charging nowadays.. and it isn't one of the goes on fire batteries either..). So it appears cutting the power wasn't such a good idea, as it appears the hard disk heads crashed or some such fail, as attempting to boot XP on the laptop after that gave a bad boot bluescreen and mounting the XP ntfs partition from Linux went into an ATA reset cycle.

So I had to watch half the rugby (it wasn't a great game in the end), and then watch some movie with Matthew McConaughty in it, at least there was scuba diving in it, so it could have been worse.

Then on Sunday on our way to the cinema, I drops my iphones on the grounds. Oh noes. My iphone volume buttons have been busted for a month or two in any case, but now the lock/power button decided to stop being useful. Of course my iphone is a US phone where I'm sure the warranty has been invalidated six ways from Tuesday at this point. So I'll probably have to go opens it ups and play with its insides. I've damaged a lot of phones in my life but the iphone has actually been the quickest to get broken, and considering I don't drink nearly as much as I used to this isn't a good showing for it.