Older blog entries for anholt (starting at number 32)

kdrive:
Spent a lot of time with the ati driver today. Got the drm-using ATI driver working in both DMA (CCE/CP) and MMIO modes. Haven't done any benchmarks. It's just a basic conversion of the drivers for r128 and radeon from XFree86 to xserver. It's still lacking, in that the kernel isn't sleeping while waiting for the accelerator to idle, and DMA isn't used for image read/write between card memory and system memory. There are also rough edges (AGP isn't detected yet, and it's probably not working on r200s).

Applied the patch from Michel Daenzer I had worked on for fbdev backend in Xati. It's a little unstable for me when I have fbdev loaded, but I've heard rumors there are issues with radeonfb on 2.6.0-test

kdrive:
Continued hacking on the atidrm driver for kdrive today. After some very helpful input from keithp, it initializes the DRI successfully on the Rage 128 (haven't tested the Radeon yet). 2d acceleration is broken after that, but it isn't using the dma engine yet anyway so there's still work to do. Out of the 886 lines of code in ati_dri.c, I'd say around 100 are device-specific (radeon/r128 split), at least so far.

I'm stuck in the FreeBSD port of the kdrive server. I'm getting a panic in vm86 mode when using VM86_INTCALL, which I was hoping would be the easy solution. I don't understand how to use the normal VM86 mode in this situation, either.

kdrive:
More work on Xati. Added the Rage 128 PCI IDs. Fixed 24-bit accel, using a cute hack (the cards don't support acceleration for 24bpp, so you put the accelerator in 8-bit mode and multiply). Got offscreen pixmaps working, improving performance. There seems to be some bug with composite, though, which I've reproduced with Xvesa. Not sure if it's xcompmgr's fault or the server's, but in some cases things don't get redrawn when dragging a window back in from offscreen. Seen some resizing issues, too. However, dragging xterms over the top of a mozilla is beautiful -- no flicker while the window underneath refreshes. I can't wait to see what things are like when we get render accel.

Issues that I know of with it, hmm. Radeon with acceleration and 1400x1050 mode doesn't work right because of limitations in pitch -- we need to do our own mode setup (hopefully we can figure out how to do that in a clean manner) or use radeonfb for that. Lacks render accel (need help from keithp for infrastructure). Lacks xv (needs to be done using 3d hardware instead of overlay). Hardware cursor not supported (insignificant, at least with standard X cursors). Doesn't use the DRM. The DRM is my next task, fixing up that poor r128drm code I had done to be used with Xati. I have this hope, and I think it's pretty realistic, that a lot of code can be shared between r128_dri.c and radeon_dri.c, so I can have a single ati_dri.c.

kdrive:
Driver in a day. I took the r128 driver from andersca and tried to make a SiS 300-series driver for kdrive. I'm close I feel, but nothing's being rendered yet. I got frustrated, so I decided to try a Radeon driver. Surprise, it was really easy, and taking code from XFree86 I got it working within a few hours. Then I noticed that Rage 128's 2d acceleration was very, very similar to that of the Radeon, so I added Rage 128 support to it. Now we've got an "ati" accelerated kdrive driver that supports both. It's got some limitations (broken at non-16-bit, like the previous r128 driver, and lacks all but two Rage 128 PCI IDs), but I'm pretty satisfied.

kdrive:
Got my DRM-using Rage 128 driver to the point of compiling, at long last. Most of the changes have been tons of tedious mechanical changes and grabbing bits from XFree86. In the process I've noticed a good bit of code that I expect to send to the chopping block (since I don't intend us to ever support the gamma DRM in its current incarnation). And maybe a bug, which would be a bug I've experienced before, but I haven't verified (lack of DRIMoveBuffers for r128). At this point it initializes the DRM, but there's some failure in int10. Note that not understanding int10 is the reason I don't have xserver on FreeBSD yet.

This means that I've got libdri (minus its glx bits which are ifdeffed out until we get glx) compiling along with libdrm.

The next major step is GLX (well, after getting this driver to actually run :-). I'm really torn about how to go about this. The easiest and most immediate way will be to bring in Mesa and do it just like XFree86 does but without the loadable GLcore. Better would be for GLcore to be buildable outside of the xserver tree and dlopenable. Best would be to either have the server dlopen a DRI driver (perhaps the fb driver) and use that for GLX rendering, or to have the server fork a program that handles GLX that the server hands off to it which then renders using a dri driver. I can see the merits of both of the last two. But I think I'll end up doing the first one first.

FreeBSD:
Continued work on xlibs ports. All but 3 (Xi, Xcursor, another I don't recall ATM) have been ported and I'm using them on my desktop. Forwarded the ports to the new x11@FreeBSD.org mailinglist which I got created to hopefully bring other people into X11 maintaining on FreeBSD so I can spend less time being frustrated with XFree86. One of our major ports PR busters has been talking about working on a kdrive port to FreeBSD.

FreeBSD:
Spent the day chopping XFree86 up into little bits. Boy, is it satisfying.

I've moved the DRI client drivers into a separate port. Hopefully soon they'll be provided by Mesa, but it'll at least make letting users upgrade to CVS DRI drivers much cleaner. Also removes a decent bit of mess from XFree86-4-Server. I'm doing a test now of XFree86-4-Server using freedesktop.org shared X libraries rather than building and linking those libraries in statically (this occurs for 4 of the servers). I've done some cleanup bits in the freedesktop.org xlibs, and I'm looking forward to rolling releases of some of them and integrating them into FreeBSD soon.

DRI:
Committed my DRM interface 1.2 change. It ties the DRM down to a specific device, which will make making a lower-level DRM layer much more sane. I have more evil plans, such as not allowing the X Server to addmap/map FB or MMIO areas that don't correspond to the areas that the card advertises through PCI. This will work well with the standalone Mesa and kdrive desires that the DRM tell userland where the FB/MMIO are, rather than the other way around.

Got a bug report from my first DRM interface change, about running two servers on different VTs on a single card, with both trying to enable the DRI. The set/getunique system which I deprecated the "set" half of in the 1.1 interface acted as a sort of lock preventing a second server from (re-)initializing the DRM. The removed "set" attempt let the second X Server partially initialize the DRM before it failed. In the process the kernel would become confused about where the lock was. So, I made it not allow a second lock-containing SHM area to be added, which locks out the 2nd X Server before it messes things up.

FreeBSD:
Played around in the PR database a bit. Closed some kern and i386 PRs, mostly due to them being already fixed. Fun to see myself shoot up to #12 of the non-ports PR busters on the PR stats page.

DRI:
Spent the day working on more DRI interface cleanups. This one ties the DRM firmly to a specific device. It should break systems with old X Servers and multiple heads that are DRI-capable in that some heads won't init the DRI, but nothing else. This sort of configuration has been relatively broken anyway, so it's not too big a deal. It removes some ugliness from the DRM, and will make future changes like the lower-level graphics layer more doable. Also, the DRM no longer offers a service of getting the irq of any pci device (now it's restricted to just the device the DRM is attached to), and the ioctl to install the irq handler no longer cares about the irq number that was set if the interface version is set high enough (1.2).

The nice part is this change doesn't even mean any modifications to the X Server, though it'll remove some code from the kdrive DRI implementation I'm working on since I'm going to insist on up to date DRM for that.

kdrive:
libdrm is compiling, and I've got libdri and a DRI-converted r128 driver that need to be made to compile now. For now it's almost all just direct copies of XFree86 code (sometimes with bits chopped out). I know there's a lot more compatibility junk we can remove, but the first thing is to get some drivers working.

As a quick explanation of these parts: libdrm is a userland API for talking to the DRM. libdri includes both the DRI* API and the XF86DRI extension. However, this does not mean "DRI in kdrive" yet as people might think -- we need GLX and I'm sure a lot more work on libdri before we can have hardware-accelerated 3d.

DRI:
Nobody's stepping up to do the creation of a lower-level kernel driver for the DRM and framebuffer to share (as far as resource allocation, perhaps DMA/IRQ handling) on Linux. It really needs to happen, and Linus and many others agree. Unfortunately, there are very few people who want to work on this sort of stuff, so I may end up having to do it myself. I think my track record on my last commits to the Linux DRM should warn a real Linux kernel hacker to do it first. :-P

DRI:
Continued work on my sis6326 DRI driver. I'm really close (well, closer than before those bugfixes), but triangles still aren't being drawn. It's frustrating, but I've been staring at that code for so long I think a break might be called for.

xlibs:
I'm planning on making the freedesktop.org xlibs the ones used on FreeBSD instead of XFree86 where possible. I've pointed out a couple of problems and fixed a couple of bugs. And committed fixes myself.

kdrive:
Finally successfully installed debian-unstable as my netboot system so I can work on kdrive. Got the r128 server working after swapping out a bad mouse (which FreeBSD also hates), and fixing scissor setup on the r128. Now I'm working on getting libdrm integrated so 2d drivers can be written using the DRM.