Older blog entries for anholt (starting at number 13)

SiS:
Got my sis6326 DRI driver (which will sit alongside the sis driver for the 540/630/730 card) to the point of compiling, including changes to the SiS DDX to load the appropriate driver. Now I need some hardware to start testing parts of it with.

FreeBSD:
Spent some time Monday looking at port fixes. Fixed some build errors on glide3 with new gcc (still need to figure out the automake issues with the new version of glide3). Also need to figure out why glean's texEnv test has decided to start crashing on me after I built it from ports. It's not my patch to the texEnv test causing it, though.

DRI:
Started working on a SiS 6326/530 DRI driver. I think it should be pretty easy, given that the hardware is very similar to, but simpler than the 540/630/730.

FreeBSD:
Ports are unfrozen, which is nice. Fixed a package building error in XFree86-4-Server. Committed various fixes submitted for XFree86-4-Server-snap, and pushed patches upstream. Still to do: the mesa-demos port, my libglut port and mesagl update, and I need to finish the glean port. I tried to update the Glide port after the new glide.sf.net release, but yet again automake is giving me errors that I don't know what to do with.

SiS:
I added the GL_EXT_texture_lod_bias extension to the SiS DRI driver last night. It was fun to be successful in implementing a feature without docs (well, I had two bitmasks to deal with, but not the format of the bits in the important one). Fixed two out of the seven broken texenv modes. Disabled the broken 3d clearing code that could make things faster but so far just makes things not work. The code now passes a couple more glean tests, and would pass several more if glean was just a little bit less strict. I'm thinking about adding a general "allow an additional bit of error" option for glean, but not sure how I would go about implementing it. Started submitting patches to glean, which I hope to continue to do.

SiS:
I finally managed to get glean, a set of OpenGL conformance tests, to compile. I wasn't following the directions properly -- you have to "make install" to build it, not "make", and it doesn't actually install the software, just puts it in the $(GLEAN_ROOT)/bin/

The initial output was an intimidating list of FAIL messages. However, the tests have been incredibly useful. It's led me to get quake3 fixed, fix frontbuffer scissoring, fix subpixel x/y offsets (fixes gaps between triangles), partially fix readpixels, and fix mipmapping. It still has issues in the following tests: blendFunc (minor), maskedClear, paths, polygonOffset, readPixSanity (24-bit depth and stencil issues), exactRGBA, and texEnv.

DRI:
I finally finished off the move of DRI CVS to freedesktop.org. We've been frustrated with sourceforge.net CVS for a while due to the 24-hour lag between commit and when the commit appears in anoncvs, along with other issues. It's taken at least a week, due to various sf.net issues. Now, we've got both anoncvs and cvsup, always up to date. That may change some day if the single box hosting things gets overloaded, but for now it's great. I'd like to say thank you to the sourceforge.net support folks who have helped us with all the support requests we sent in trying to get this done.

FreeBSD:
Finally committed the XFree86-4-Server-snap port, which is the server part of the 4.3.99.12 development snapshot. I'm now using that with the new DRI CVS layered over the top. Very nice on the 8500, so far. Committed and MFCed a typo fix to the Intel AGP code from the most detailed problem report I've ever handled -- the submitter looked at the current code, the FreeBSD 4.6 code, the linux equivalent of that code, and tested all variations, with just-short-of-patches included. Plus the testing involved starting XFree86 many times to reproduce the bug. I also spent a significant portion of the night talking with Silby about a problem with my Via Rhine onboard nic and how to debug them. The debug printfs unfortunately/fortunately seem to have suppressed the issue, though.

SiS:
Committed my DRI update for the SiS to CVS today. It's doing pretty well -- the mesa demos I've tried so far work and tuxracer works. Quake3 unfortunately has major rendering issues in-game. Still need to get AGP support fixed up for the new infrastructure, but I was happy to hear that it worked for someone with an AGP card anyway. For now I'm looking at what GL extensions will be easy to implement.

SiS:
Ported the SiS DRI to FreeBSD, and in the process removed the requirement for sisfb for SiS DRI (requires new X Server and DRM to work, which also means it requires the new client driver, too). My goal in this was to see if phkmalloc would find what was going on in tuxracer better than I could on linux. Basically, on linux tuxracer is crashing in free() of memory that was allocated with calloc() and is still allocated as far as I know. gdb is still happy to print out the structure being freed. However, on FreeBSD tuxracer worked just fine without crashing. Now I need to find some sort of memory debugger for linux, hopefully something I can hook up without requiring changes in compiling. dmalloc wasn't doing anything when I tried using LD_PRELOAD.

Turns out the problem with r128 was that I was looking at the code from trunk (which was good) while testing using config-0-0-1-branch, which didn't have the fix for alpha testing that was in trunk. Happy to see another bug I knew of squashed.

SiS:
Got some basic texturing working over the weekend, and got the big one I wanted to get working done: the fire demo. Sure, it's no quake3, or even tuxracer, but it's being rendered better than with the r128 driver now :) (And I've stuck figuring out what's wrong with the r128 driver on my todo list). At this point I've got glxgears, geartrain, tunnel, ipers, fire, multiarb, ray, morph3d, isosurf, and spectex working. gloss, texenv, teapot, reflect, and a few others are not working, besides those that don't work due to lack of GL extensions. Oh, and tuxracer doesn't work for some reason I absolutely cannot figure out. Plus I've got to get the AGP vertex output into the new driver, which I'm putting off until I can get an AGP card.

SiS DRI:
Finally got glxgears running hardware-accelerated with the SiS. It was pretty exciting, but it's only running at ~65fps, compared to ~65fps in software. I'm not sure how fast the card should be running (it's PCI only) -- it's spending something like 95% of the time in the MMIO write of a quad to the card. I've decided not to think about that and try to get the rest of the driver working, such as textures. But if I thought getting colored triangles was hard, this texture stuff looks really hard. I've started trying to learn OpenGL so I can understand this better, but after about page 60 of the spec I wanted to bang my head against something. Probably I should go through some tutorials, then attack the spec.

LinuxFund:
I've been hired by LinuxFund as a part-time coder on various projects. It's part of a stipend-type program they're trying out for students. So far I've begun work on porting the ADMTek wireless driver from NetBSD to FreeBSD then linux (needs a ton of work still) based on Sam Leffler's wireless framework for linux/FreeBSD, committed my Rage 128 pageflipping code to DRI CVS, and I'm currently spending my time on getting the SiS DRI working in DRI CVS.

Perforce:
After hating CVS for a long time, I've started seriously playing with Perforce to manage code I'm working on. Trying to produce diffs and merge between branches/dates has always been terrible for me with CVS in the DRI project. I'd started using perforce in a basic manner for FreeBSD with the plex86 stuff, since we have a perforce repository for WIPs in the project. I started doing the SiS work in perforce, and the ease of committing and reviewing what I did in small but multifile changes has been great. So I decided to use it to solve my problem of merging the DRM between DRI CVS and FreeBSD. The problem is that the DRM has to be changed somewhat to live in the kernel tree. Before, I would copy the files manually from DRI CVS into the kernel tree, apply a script to edit the #includes, and then manually re-add the $FreeBSD$ tags required by FreeBSD's CVS. Big ugly mess. So I set up a p4 repo, imported DRI CVS's DRM, branched kernel-drm, and changed kernel-drm to match the kernel. Then I made some necessary changes to DRI CVS, imported them to p4, integrated to kernel-drm, realized I needed more changes, and repeated a few times. Each time there would be a conflict or two, usually around the header files, but other than that there was no merging work, unlike the merges from trunk I had tried to do on branches in DRI CVS. Then I took the kernel-drm files, slapped them in the FreeBSD tree and was done. It sounds like if there's some change made by someone in the FreeBSD tree after changes happen in DRI CVS, I can submit it to my kernel-drm branch, import DRI CVS to the dri branch, and reverse-integreate that specific change to the dri branch to commit to DRI CVS. sweet.

Of course, it's a closed-source tool, and has licensing restrictions. However, a FreeBSD committer mentioned that arch looks like a near replacement for p4 at this point. Took a look, and it seems to require some more work than p4 does, but still sounds very similar. Maybe I'll try it for the next project.

DRI:
I've committed a few tiny cleanups to the DRM, but most of what I've done recently is work on the SiS code. I've got almost all of it changed over to how things work in the post-mesa3.5 world, except for sis_render.c and sis_texture.c, and some of the state change functions. The state change functions are simple -- hooking them in through a different function and changing any references to structure names that have changed since Mesa 3.4. sis_texture.c will be easy, except that it depends on a lot of the render code (for sw fallbacks, etc.). So I'm stuck staring at the render code. There is no documentation for it besides the source and diffs between mesa3.4 and mesa3.5 versions of other drivers. What's got me stuck the most is that this driver is different from the others. i8x0, Radeon, R200, Rage128, and MGA all submit DMA buffers to the kernel, which then get run by the card. The SiS, on the other hand, uses MMIO in the client driver (sis_dri.so) so I can't just steal from r128 for the new render code. I think the closest to what I'm doing is 3dfx, which uses MMIO indirectly through Glide, but Glide hides a lot of complexity in the client driver I think.

FreeBSD:
Updated the FreeBSD-current DRM to DRI CVS. Also made a port of the 3.0 beta Matrox drivers. I was somewhat disappointed in these -- there is no license file in the tarball itself, so I'm not sure if it's covered by the "license" that's mentioned in the readme that sits next to the file in the ftp directory, or the extremely restrictive generic license most people click through to get to the file itself. If it's the latter it makes a port basically useless, as people have to compile the driver themselves, and doesn't allow FreeBSD to redistribute the HAL which enables some significant features for some cards. Furthermore there were blatant problems in the source itself. There was a #include "/opt/xc.430/programs/Xserver/hw/xfree86/os-support/xf86_ansic.h" and some debugging #defines left around. Makes me question the other unexplained changes between the source included and the stock XFree86 4.3.0 source.