Below are the 20 most recent journal entries recorded in Eric Anholt's LiveJournal:

[ << Previous 20 ]

Friday, September 11th, 2009
5:14 pm	goodbye internets This Sunday I'm heading out on a bike trip through Oregon and Washington with my housemate's dad's family and friends. 50-70 miles a day for 7 days. Gear hauled by car, sleeping in hotels, and eating out all the time. The first two ground rules that were sent out: The morning of the ride we draw straws for SAG wagon driver order. Everybody drives a half day. After everybody has driven once we negotiate. Afternoon driver responsible for buying a fifth of Jack Daniels and three or four six packs of good beer, plus chips and salsa. Also some soda. You probably won't hear from me for a while. I don't exactly intend to be merging patches in the evenings. I've certainly been busy with patches recently, though. The big update yesterday was http://lists.freedesktop.org/archives/intel-gfx/2009-September/004122.html -- those nasty 8xx hangs with GEM should now be fixed in drm-intel-next, to be landing in a 2.6.31.x near you soon. I've spent a long time on this bug, and we came incredibly close to fixing it with the clflush idea on the 8xx_chipset_flush() back in March, but the fact that we were writing to an uncached page meant we completely bypassed the cache we were trying to flush. The 2.6.31 kernel is finally out, with a lot of improvements in our graphics driver and only a slight delay in releasing due to us screwing up (uh, let's not do that again). One of the biggest additions is DisplayPort support. DP is like HDMI done right -- more bandwidth, nice connectors, better compatibility story, and a low power design for use inside of laptops. keithp wrote the code and has been using it on his x200s's dock, and I came awfully close to picking up an x301 which has it on the laptop. KMS is also in much better shape once again, with a ton of work from Ma Ling, Zhao Yakui, and Jesse Barnes. It's also nice in looking back at the log to see a lot of fixes for serious issues in from non-Intel folks -- integrating with the community is continuing to pay off for us. My contribution this cycle was generally GEM stability fixes again, though a number of fixes came from Chris Wilson's careful reviews of the code. I've also fixed what I think was the last major regression for texture tiling, which is around a 30% win on many GPU-bound OpenGL apps on the 965 and newer. That'll be landing on by default in Mesa 7.6. On the plate for 2.6.32 is framebuffer compression support for around a .5W power savings, automatic downclocking of the GPU when idle (no need for user power management, and another .5W or so), experimental new GPU reset support from Ben Gamari and Owain Ainsworth (That's right, an OpenBSD developer), and of course more KMS fixes and new hardware support. We're also probably going to land execbuf2, which will let us do texture tiling efficiently on the pre-965 hardware. Most of my time recently, though, I've finally been able to get back to spending serious time with Mesa after being stuck in 2D and the kernel for years. It's where I enjoy working, despite the build system and development model. In the last few weeks, I've added support for ARB_sync, ARB_map_buffer_range, ARB_depth_clamp, ARB_copy_buffer, and ARB_draw_elements_base_vertex for our hardware. All but ARB_depth_clamp (AKA NV_depth_clamp) work on pre-965 hardware as well. I also fixed up some major performance penalties for applications using OpenGL correctly. I of course found these by writing an application using OpenGL the way it should be used as of the last 5 years or so. Unfortunately most open-source software out there fails in that respect (thinking in particular of OpenArena, blender, and the various TuxRacer forks, being what seem to be the most popular offenders). One fix was a 50-100% fps improvement, and another was a 70% CPU usage win. I'm going to be working on NV_primitive_restart support soon, which will be another CPU usage win, and likely a performance win as well on the 965. Another big change for us has been the addition of Ben Holmes to our team. He's a fellow student in idr's OpenGL class, who's been writing tests for us. A lot of bugfixes I've done recently have been "hey, Ben, I think there might be a problem if an app does the following thing." He writes a test in piglit, tests that it fails, sends it out, we add it to the tree, then go fix the driver. Today, I got dFdx()/dFdy() fixed in our GLSL support by exactly this method. Unfortunately we'll be losing him back to school soon, but it's been well worth it so far. (10 Comments |Comment on this)
Wednesday, July 22nd, 2009
9:19 pm	Another quarter, and another release. I think we've made big progress here. One of my favorite reports on the mailing list was that a company deploying our graphics driver was delightfully surprised that their XV tearing issues were fixed. That was a lot of work, and I was despairing of them saying it didn't work out. A few things I was involved with that I'm happy with: - Fixing the "memory leak" of GEM buffer objects - Fixing quake4 and doom3 which regressed back in Mesa 7.4 - Fixing VBO performance on 915 (I don't like discouraging people from doing the right thing) - OpenGL Performance and correctness fixes for cairo-gl - Fixing a bunch of FBO problems, particularly on 965 - Hardware-accelerated glGenerateMipmaps and SGIS_generate_mipmap. Finally. - Fixing many GLSL bugs on 965. - Fixing occlusion queries (sauerbraten) - Fixing crystalspace regression (woo supporting other open-source software developers) - Fixing ut2004 hangs on G4x. Already, things are looking exciting for our next release. Thanks to cairo-perf-trace, I've just landed a 10% improvement in firefox performance for UXA. We're also working towards the future with cairo-gl, which I'd started doing in my free time based off of ickle's cairo-drm work, and is now merged into cairo master. This is a major step towards maintaining one driver (OpenGL) per chipset, with the other part being doing a real X-on-GL backend so that legacy stuff not using cairo doesn't suffer too badly. Both of these are now on our plates for work activity in the next few months. But we've got a ways to go to get there. I know we've got fixes to be made to our OpenGL before cairo-gl's going to shine, and cairo-gl needs a lot of work as well: [ # ] backend test min(s) median(s) stddev. count [ 0] image firefox-20090601 92.877 108.208 6.54% 15/15 [ 0] xlib firefox-20090601 46.609 46.832 0.28% 6/6 [ 0] gl firefox-20090601 238.103 238.195 0.35% 5/6 (tested with master of everything on a 945GM, lower is better) One of the things we need to figure out is what sort of shader support cairo-gl's going to be based on, and what we want to do in our driver to support it. The 915 and other hardware of that era can't do dynamic flow control, so many GLSL shaders would be unimplementable. But we as developers of software targeting GL on these chips would love to write in GLSL instead of ugly ARB_fragment_program and ARB_vertex_program, even if we know we can't use some language features. We could maybe expose the GLES GLSL extension on 915, which explicitly says that programs with dynamic flow control and other features missing on this generation of chips may not compile. We could also be sneaky and do it on desktop OpenGL GLSL and be within spec (I think, and afaik some closed vendors have done it as well), though some apps might get angry with us for doing so. This is up in the air, but I'm hoping our answer is "expose it". (Oh, and other people are doing exciting things, like jbarnes and mjg59 making big power savings, but I'll leave blogging to them) (8 Comments |Comment on this)
Friday, May 29th, 2009
9:18 am	Things are continuing to settle down in the Intel graphics driver. We're in the ~5th month of driver stabilization, and I think it's starting to really show. One of the key things we've done recently is remove the old options in the 2D driver. We had proliferation problems before where everybody was running a different configuration (XAA or EXA or UXA, DRI1 or DRI2, KMS or not) to get their particular usage working well. So we'd fix someone's configuration, and break someone else's. The moment I cleaned out all that, we suddenly fixed a bunch of bugs with the path you should be using (UXA, DRI2, KMS) that had been obscured by the mess all over the driver. But the 2D driver's actually been pretty quiet -- the cool stuff is in: commit 3da9e9d34ed7d2f5c33fd194d9dd09e15f4e51c0 Merge: 44ada1a 07f4f3e Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Fri May 29 08:48:13 2009 -0700 Merge branch 'drm-intel-next' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel We've been making continual incremental improvement to the kernel code. The driver quality hit a low point around January when we were landing our last features we'd been developing over the previous year -- KMS and DRI2 in particular. A lot of it was deadline driven, and we had to land things sooner than we probably would have otherwise. But every week since then we've been turning around nice fixes and I'd like to mention just what happened this week in the kernel here: krh fixed the swap-related corruption This turned out to be a bug with our GTT mapping where we got some cache domain management wrong. GTT mapping is a great performance feature -- when you're uploading data to the GPU, instead of writing it to memory, flushing the CPU cache, and having the GPU access the buffer, just write it through the GPU's aperture. The streaming write performance is basically the same (it's a 50% win to a 50% loss in microbenchmarks, in the noise at a macro level), but the important thing is that it avoids sucking up your CPU's cache space for data you no longer want in the CPU's cache. If it means that your app starts fitting in L2 or L1 when it didn't before, the results can be huge. Only, we made a mistake. When an object wasn't in the GTT aperture, touching your GTT mapping would fault the object in. We would forget to set the cache domain of the object to the GTT. If the CPU hadn't touched the pages, it worked out, or if the object had been bound to the GTT before userland started down the faulting path it worked out since userland asked to do the domain transition. But in the case of swapping of GEM objects, the CPU has the object in its cache since it was just DMAed from disk, and we silently dropped the user's GTT domain transition request because the object wasn't in the GTT domain yet. So we faulted it in, wrote some data uncached into the object, and later on down the line the CPU cache lines got flushed out to it. You ended up with old glyph data on top of your new glyph data. The solution was to do domain setting at the right time -- when the object gets bound to the GTT in the fault handler. I fixed 8xx 3D rendering Since around January, 8xx 3D's been in bad shape, most of it related to tiling. Daniel Vetter came along in March and fixed it up pretty significantly -- the untested port of userland stuff to the kernel had been quite wrong. Only, it turned out that Daniel's stuff was also a mis-translation of the working userland code to the kernel, and since he didn't have the docs it wasn't as easy to debug as it should be. I did have the docs, so after a day of sitting down and investigating this model bug report comment by Daniel, I had a fix for the kernel for stride issues, and a fix for a Mesa regression for resizing issues. We're still working on getting docs for these old chipsets out, so that people don't need to get blocked on us. Sadly, it's slow going -- our group doesn't have the authority to do release the docs, so we have to convince other groups (who have other business to be doing) to spend their time going through the process to get the docs released. I applied a big workaround for 865 cache flushing. There's something weird about the 865. People that have been following our development probably know a bit about how we do weird cache management things. In particular, for getting an object in the CPU cache accessible by the GPU, we map each page of the object to the CPU, clflush each cache line of the page, then write to a magic register to flush the chipset's cache of flushed CPU cachelines out to memory, at which point the GPU can actually see them. This works beautifully (and much faster than using kernel mechanisms to manage PTE cachability flags) on all the other hardware we have. But on the 865, if you started up X -retro, it would show that some of the little blits drawing the root weave wouldn't appear. The blits are 32 bytes each, or half a cache line, and generally they'd be missing in groups of two. It's as if cache lines didn't get flushed, and the GPU saw zeroes (the original contents of the page) instead of the new values containing blit commands. krh did a bunch of experimenting, and nothing else we came up with helped except for wbinvd. So when we're CPU cache flushing the objects on 865, we now do wbinvd instead of mapping pages and clflushing them, and the desktop appears to be stable again. After some more investigation of docs, I've got a couple more experiments to try, but at least 2.6.30 should have working 865 support. So, that's it, folks. One week of kernel fixes, and we've got rendering and stability improvements across the board. I'm hoping next week I get do do work, I can sit down and figure out the memory leak with GL compositing -- we just got a simple testcase posted on the mailing list that's supposed to show an actual leak, and I want to take a look at it soon. (12 Comments |Comment on this)
Tuesday, February 24th, 2009
2:55 pm	Things have been pretty quiet on the intel graphics driver front for a while. After all the churn of FBOs, GEM, DRI2, and KMS, we've been settling down to seriously stabilizing the driver. Things are looking pretty good -- KMS is now suspending/resuming, resizing framebuffers, supporting rotation, and generally looking relatively correct on the machines we're testing on. A number of DRI2 performance regressions are fixed. We've fixed some tricky little bugs in GEM cache handling. Big thanks goes out to the RH guys (airlied and krh) for pushing so hard on this code and fixing a bunch of the sharp edges instead of just filing bugs, and to ickle for reviewing and fixing piles of error path problems in the DRM. I love working with this community. We're now ramping up for the Q1 release, which means we're switching from what has been nearly 100% time on bug and regression fixing to 100% bug and regression fixing. I just pushed out xf86-video-intel 2.6.2 to get some of our stable fixes into the world so people have a better base for testing KMS. By the end of March we should have a new release out with current 2D, a new Mesa tarball with the latest fixes since 7.4, and hopefully a kernel 2.6.29 with KMS. In my spare time I've been working on a GL backend for cairo. My assertion for some time has been that anything we're doing with accelerating Render, we could do with less developer time and faster runtime with GL. It took about 2 weeks of me flailing around learning how to do GL, and I got cairogears up and running at about 4 times the speed of Render, on various 965s. The code's still pretty rough -- it doesn't check for extensions it needs, relies on NPOT textures when it could use rectangular textures, doesn't do shaders for gradients, etc. But actually most of the time on the code has been spent fixing our 3D driver. There were some texture upload issues, BO cache explosion issues, drawpixels issues, DRI2 viewport overhead issues, and my current one is that the latest commit in cairo-gl ends up hanging both 915s and 965s after a while in cairogears. I'm hoping some other people interested in this stuff might feel like picking it up and playing with it. It's not terribly complicated code, I don't think, there are other backends to compare to, and cairo's test suite is wonderful for validating what you're trying out. The code is in: git://people.freedesktop.org/~anholt/cairo on the gl branch git://people.freedesktop.org/~anholt/cairogears on the gl branch (8 Comments |Comment on this)
Tuesday, December 23rd, 2008
9:00 pm	snowmageddon I've been enjoying the snowpocalypse. The first few days were pretty fun, as with an inch or two you could bike quite well in it, yet the streets were almost empty of cars. Except for crazies who insist on passing you under any circumstance, and with minimal room to spare. Still, mostly of the time it was good, and people got a kick out of me on the brompton in the snow. Some hippies stopped, got out of their car, and asked to take a picture of me to "document their day". Sure, no problem. Then they asked if I was carrying a piece, and I was amused to find that despite selling out I can be mistaken for the kind of person who would smoke a bowl with strangers in broad daylight. Biking in the snow. Scaled down picture so you can't tell that my camera is angry about the soaking it got this summer/. By Sunday morning, though, biking was pretty much out. 3" of snow or so was more than I could successfully plow through, so walking and biking were about tied in the mile or so I did getting home, and the walking was a lot less comical. So I've been walking and taking the bus/MAX since. Everybody I know is stir-crazy, frustrated by the snow, and yet I think I've been out of the house more than I usually am. (1 Comment |Comment on this)
Friday, December 5th, 2008
12:26 pm	excitement in X land A couple of major milestones this week: - DRI2 merged to intel master and server-1.6-branch. We'll have DRI2 in this server release, seriously. We don't have DRI2 vblank-synced swaps going, but we should be able to make Mesa do its old path (wait for vblank, then ask DRM (now the xserver) to do the swap) and have people mostly happy with that. I just ran xcompmgr -c and glxgears at the same time and it was everything I thought it could be. - DRM modesetting merged to drm-intel-next. That means we're planning on having this working, seriously, for 2.6.29. It's ready to test today if you've got a lucky platform, with sudo modprobe i915 modeset=1, then using drmtest from the modesetting-gem branch of libdrm, or libdrm from that branch plus xf86-video-intel built against it. I hear the 2D driver needs a bit of love again after recent shakeups, but that may be unfounded rumor. I'm doing my best to dogfood the whole mess on my development system, as we're planning on having DRI2 and GEM stable for release this month. I've got some misrendering with UXA, though things are much better today than before (Thanks Pierre Willenbrock!). 965 3D's in pretty good shape since my last fix, and I've been using it most days to play Eschalon. We've still got IRQ issues on GM965, though, as long as it's not my GM965. Plenty to keep us busy this month. (5 Comments |Comment on this)
Saturday, October 25th, 2008
2:35 pm	Linux on the HP 2530p Two weeks ago or so I got a lovely new laptop, the HP Elitebook 2530p, but quickly found that ACPI on it would make it hang at boot. I installed with acpi=off, and used it as a desktop-style testing machine while we tried to figure out what was going wrong with it. It was kind of rough, as someone who's never debugged ACPI before -- the googling gives you documentation that advertises itself as stale (so why does it exist?), and the real documentation isn't where it should be. The ACPI guys I know seemed stumped -- various debug output all came up clean, yet enabling ACPI caused boot-time hangs in the ACPI battery, ACPI thermal, and HDA drivers. It turned out after I nuked a bunch of BIOS options, that the option to enable the fan while AC is on is what was causing it. Disable it for linux on 2530p happiness. Also, suspend/resume works out of the box, as long as your box includes loading the Intel DRM. (3 Comments |Comment on this)
Tuesday, October 21st, 2008
11:12 pm	doing it right Things are looking up in the Intel driver. The GEM work has landed in Linus's master, meaning that at this point we can worry about just fixing our bugs, and know that it's going to end up in 2.6.28. But what gets me even more excited than getting our first major kernel merge done is that we're starting to create a culture of review surrounding our driver. Keith started by insisting on posting patches instead of git trees, which meant that I read his patches and found issues before they were queued for upstream. I started posting patches in retaliation, and he kept NAKing them for needing improvements (which I've usually got around to) or being obsoleted by better work he did. Now we've got the rest of the team joining the party. While it has slowed things down a bit, it's also nice -- the internal TODO list of "someone committed some junk and I need to go fix it up when I get some time" is no longer growing out of control, and stability is definitely increasing. The majority of the improvements in the last week have been in vblank handling. The vblank-rework changes had gone through a series of QA cycles before I merged them, but there were some issues that cropped up in integrating them with the GEM changes, and there were some plain old bugs we found when we started trying to use them on our desktops. We also fixed some VT switching bugs that would have hurt suspend/resume, and a couple more G4X issues. My highest priority now is sorting out our failures with batchbuffers being too large. Our testcases up until now have had texture load below the size of the aperture. However, with more interesting apps like sauerbraten or Virtual Forbidden City, we're running into a problem where we accumulate a batchbuffer for execution that can't be loaded into the aperture all at once, and you get an error message and no rendering. Dave Airlie had fixed this in classic mode with his check_aperture changes, but we never did them for GEM, since figured we'd have the whole aperture available instead of just 32MB. But when a single mipmapped texture is 24MB, we run out of aperture quickly anyway. There are a few things we're planning on doing to resolve the problem: Implement check_aperture on GEM so that we can flush the batch when it's likely going to be too big for the aperture. This will avoid having rendering dropped on the floor for being too big. Fix counting of aperture space consumed in check_aperture. Right now we just sum up all the sizes of buffers targeted by relocations, but if you keep referencing the same big buffer over and over you'll flush too often. Implement PPGTT support for new chipsets. This gives us a 2GB virtual address space for your batchbuffers to play in instead of 256 or 512MB. I'm trying to avoid saying "that'll be enough for anybody", but it'll certainly make a lot of apps happier. This'll be a bit of work, as we don't have a PCI aperture mapping to that address space, so we can't use some of our old tricks the same way. However, it should be a pretty significant win on any serious 3D workload. We're also looking into getting an appropriate API into the kernel for our transient mappings of the aperture. One of the sticking points in getting GEM merged was a hack we were doing with the kernel mapping APIs on CONFIG_HIGHMEM x86. By actually sitting down and writing the API we need, we should get improved performance in PAT non-MTRR environments (like the G[M]45 where we don't get an MTRR slot), and improved performance on 64-bit where we couldn't do the CONFIG_HIGHMEM hack, for a 20% to 200% improvement depending on which case of failure occurred. By being in a kernel tree, we can submit a single patch to the kernel community showing the API we want and how we plan to use it, and get much better feedback than we've been able to in the past. In this case, Ingo came up with fun ideas for how we can get the advantages of our atomic mapping path on CONFIG_HIGHMEM x86 without the scheduling restrictions of actually being atomic, which would be awfully convenient for one of our code paths. For those looking to run the latest hotness, here's the list: kernel: drm-intel-next in my tree (still has some bugfixes to be merged) libdrm: 2.4.0 (nothing major has happened since then) xf86-video-intel: 2.5.0 (nothing major has happened since then) dri2proto master inputproto master xserver: master (be sure to update your input drivers too!) mesa: master That's 2 things with version numbers on them compared to 2 weeks ago. The X server would be in the list too, but we missed that the glyph cache didn't make it into the 1.5 series, which is critical for 2D performance. (15 Comments |Comment on this)
Tuesday, September 30th, 2008
2:03 pm	moving to kernel.org I've finally got my kernel tree up on kernel.org. It took a couple of weeks to get an account, then a couple of weeks to find the time to worry about it. http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=shortlog;h=drm-intel-next git clone git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel This should be the place where all of our future "ready for upstream" work goes. So, for example, if you're looking to test GEM, grab these branches: kernel: drm-intel-next libdrm: master xf86-video-intel: master mesa: master If you're looking to test dri2, it's a little more work. Grab these: kernel: drm-intel-next libdrm: master dri2proto: master xserver: master (then edit hw/xfree86/Makefile.am to uncomment dri2) xf86-video-intel: dri2 mesa: master (15 Comments |Comment on this)
Friday, September 12th, 2008
4:15 pm	taste of success As part of the work we're doing for Moblin, I got our head trees in shape for GL compositing on GEM. We had a nice demo of the technology at XDS from krh, and today I got the same setup working: glxgears and totem on a cube all playing nicely together. It feels like things are finally coming together, and we'll be ready to support this stuff in releases soon, even if it won't be at the end of this release cycle. All the code's in master, and available to test. The usual warnings about master apply, and just to show how serious we are about our in-development code, among the known issues are: Can't do UXA (and therefore DRI2) with tiling. It's kind of hard to teach X about tiled buffers. NVIDIA went with wrapping all pixel access from libfb to produce libwfb. Our plan is to return to GTT-managed access of buffers in the X Server so we don't have to teach it about this -- we keep the nice write-combined performance we're used to with framebuffer access, though we also suffer from painful read performance we're used to if we have fallbacks that read (See also: Render gradients and convolutions). 2D performance has tanked when you use UXA. If you fallback on front buffer rendering with the X Server, GEM goes wild with cache flushing because the X Server isn't telling it just what memory it touched, yet we're telling GEM that the results need to land in the front buffer "soon". This means that compositing is fast, but non-composited isn't if you run emacs or gitk anything else that causes fallbacks. There are a couple of potential fixes for this, but the current plan is to avoid it using GTT mapping, which resolves the coherency issue. Long term, we're going to be adding support for telling GEM what pages we touched after the fact (or maybe use fault-based clflushing) for OpenGL, and at that point we may reconsider how X maps its buffers. 3D performance has tanked in some cases Haven't debugged this one, and it's next on the list. Can't reproduce on the test systems here. Applications hang on to a lot of buffer objects In TTM we would allocate giant buffer objects and then suballocate out of them, because allocation performance was so slow. This meant that userland had to pay attention to a lot of fencing issues (and you had to expose the idea of a fence) so that you could know which pieces were still used. We went with a simpler model for GEM, where the userland caches buffer objects of similar size, and reuses them when the kernel tells us they're no longer used by the GPU. By returning "freed" buffers to the cache, we get wonderful performance when an app is running flat out and allocating and freeing buffers like mad. However, as we think about cairo moving to a GL backend, and all your apps sitting waiting for input hanging onto these cached buffers, the memory usage is likely to become an issue. They're pageable, but that's slow and we're looking at systems with limited memory+swap anyway. Instead, we need to free buffers when they're not serving any use in the cache. One way we're thinking about is on allocate, when a cached buffer is "really old" (seconds), actually free it. That still leaves some excess memory laying around when an app does some rendering and then stops for input. The long-term solution would be for userland to tell the kernel when it wasn't going to actively use a buffer and the contents could be thrown out. Then, in the memory pressure callback from the kernel, we can throw out cached buffers and nuke mappings, and userland has to allocate new ones when it needs. (7 Comments |Comment on this)
Monday, August 25th, 2008
1:46 pm	eee 901 wireless updates I got a lovely little eee 901 for work. It mostly seems like a useful machine, except for the position of the right shift key which is a disaster. (Placing my fingers on the home row, I've hovering over the up-arrow instead of shift. Hilarity ensues when trying to type '~' in the terminal or working on spreadsheets in any way). However, the wireless driver isn't integrated into the kernel yet, and the old driver tarball is already broken on 2.6.27 release candidates. I was having a hard time finding who was working on it or where the code was. So, I cobbled together the patches I found wandering around the internet, and put up a git repo: git clone git://anongit.anholt.net/git/rt2860 Don't expect this repo to necessarily get updated, but it'll probably get you going if you're on 2.6.27-rc2 or so today. (12 Comments |Comment on this)
Thursday, August 21st, 2008
2:07 pm	continuing GEM progress Just got back from a week in Hawaii with the family.  It was great to finally take a break, and come back refreshed instead of feeling overwhelmed. Two weeks ago the good news for GEM was getting ReadPixels to go fast.  It should be fast under our architecture, since we can map the pages and get at them cached.  We just didn't get around to making sure that was the case for a while, and it turns out we had some traps.  Conformance tests that go and write a pixel, then read the value, then write a new pixel etc. were taking hours instead of the minutes that they should.  The fix was to make the fallback spans code (which is how our ReadPixels is handled, though this is pretty pessimal) use pread instead of mapping and reading the contents out.  This gave the kernel the information it needed to not clflush the whole buffer when you just needed a little bit out.  That fixed the conformance tests.  Once I combined that with a little cache of pread data so I didn't syscall per pixel, I was getting faster large-scale ReadPixels out of GEM than we'd seen out of the aperture reads that the driver's always used before.  And there's still significant room for improvement. ReadPixels shouldn't be important.  In theory apps aren't doing this, since ReadPixels is so slow on just about everyone's hardware that you should figure out some way to get around using it.  But it turned out that at least gl-117 was actually using it, and it was a performance bottleneck, which is now almost gone (~10% of the profile).  So in this case conformance testing ended up forcing us to fix a real app bug. I also fixed a couple of performance regressions seen on the 965 with openarena -- one was a failure in the drm-gem-merge branch, and another was cache ping-ponging for vertex/index buffer uploads since GTT mappings started happening.  It's now back up to 76 fps from 28 fps. With our recent fixes plus the changes in response to lkml review, I'm ready to take another stab at getting into linux-next.  That's the gating step for releasing libdrm, then the 2d driver, then making an appropriate mesa tarball, then getting all the new hotness into distros.  It's been a long time coming. (Comment on this)
Tuesday, July 15th, 2008
3:30 pm	GEM and buffer objects Keith has noted the adventures that we've recently had in the GEM branch with the disagreement between the CPU and GPU about how memory gets addressed. We've got a pretty decent solution now I think, though I'm having some troubles getting the MCHBAR mapped on desktop 965s, so I can't tell what mode the CPU is in. I automatically disable tiling in that case, to avoid broken rendering. Apparently the MCHBAR's locked out so that mortals don't go in and break their memory configuration. But overclockers have figured out how to unlock it, so I'm sure we will figure out as well in due time. Next project for me is fixing issues with PBO and FBO. While we enabled support for the ARB_framebuffer_objects and ARB_pixel_buffer_objects on 965 with TTM/GEM development, that implementation from the 915 came with a lot of bugs that we haven't got around to fixing. Now as more people are looking to use buffer objects, we need to get those bugs fixed. The first issue I've found is that we're not flushing batchbuffers full of rendering before mapping buffer objects. This will anger conformance tests that do rendering then read the resulting data out immediately. I wrote up a fix for this today that I'll be testing in the next couple of days. The second is that we're trying to use the 2d blitter for accelerating copies between buffer objects and the screen. That's things like glReadPixels to a PBO, glDrawPixels from a PBO, glCopyTexSubImage, glCopyPixels with read != draw drawable, etc. The trick is that for buffer objects we render them upside down compared to the shared front and back buffers. So when we're blitting between the two we need to invert the data -- set a negative pitch on one of the buffers and a base address somewhere at the other end. The blitter's supposed to be cool with this. Except that there's this comment in the code: /* Initial y values don't seem to work with negative pitches. If * we adjust the offsets manually (below), it seems to work fine. So we need to not just put the offset somewhere on the other side, but exactly so that y == 0 in the offset we set is the end of the blit area. Combine this with the fact that for tiled buffers the offset has to be 4KB-aligned, and it means that we're probably going to be angering our blitter if you choose unpleasant offsets for the the part of the blit that's in the shared front/back/depth. I might be able to work around it today by just flipping the buffer that isn't tiled instead, assuming that both aren't tiled. But we want to get to the point of tiling them both. I think the right solution here is to just ditch using the blitter for almost everything. If we figure out how to add meta operations to mesa for these sort of pixel path operations, we could write generic acceleration for anybody who wanted to use it, by mapping them to normal GL operations using texturing. While it's some CPU overhead for state management, the 3D path is supposed to be faster than 2D GPU-wise, and it would get rid of a bunch of metaops code inside of our driver which has proved to be fragile at best. In the next week I'm hoping to work on getting some metaops set up. Beyond PBO, it would also help us for implementing accelerated SGIS_generate_mipmap, which is currently hurting compiz and other apps, and more complete glBitmap which is hurting mesa demos (and we know how important those are). (2 Comments |Comment on this)
Wednesday, May 21st, 2008
4:07 pm	On the Rain-Slick Precipice of Darkness and Mesa I was very excited for the release of On the Rain-Slick Precipice of Darkness. Unfortunately, it appears to be broken on open-source graphics drivers. After a bit of debugging with some folks on the forums, it looks like the game is testing for OpenGL extensions before creating a GL context. Since we only load the driver at the time someone makes a direct context, we have no idea what to return for the extension list, and just return NULL. The game appears to take that answer and get all indignant that we don't support things like ARB_multitexture. They're looking into it, and hopefully we'll have a playable game soon. (4 Comments |Comment on this)
Friday, May 16th, 2008
12:51 pm	freedesktop.org mess EDIT: daniels (the guy doing all the work) posted a good summary of what happened to fd.o to announce@, so I'll quote that: Hi, Due to the recent Debian OpenSSL trainwreck[0], we've had to do a fair bit of housecleaning with regards to authentication. Firstly, the host keys have been regenerated, as below: root@fruit:~% ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key 2048 1e:81:13:df:b9:68:fc:c2:ec:9d:c3:87:d1:5e:30:77 /etc/ssh/ssh_host_rsa_key.pub root@gabe:~% ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key 2048 c1:1a:8a:e5:99:ce:5a:d9:a9:e2:b3:95:67:95:9d:f7 /etc/ssh/ssh_host_rsa_key.pub root@kemper:~% ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key 2048 95:b5:28:3d:9b:37:55:d4:fc:3d:99:b4:06:9d:9b:5f /etc/ssh/ssh_host_rsa_key.pub root@annarchy:~% ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key 2048 32:3e:0c:df:0a:c8:a6:33:72:9c:6c:ba:68:58:d2:30 /etc/ssh/ssh_host_rsa_key.pub You'll note that these are RSA-only. DSA is no longer supported, nor is SSH1. Secondly, all vulnerable keys (weak RSA keys, RSA1 keys, and DSA keys) have been removed; anyone who had a vulnerable key will have received an email from myself at whichever address you had in LDAP, explaining what happened, and how to fix it[1]. annarchy.fd.o (hosting bugs.fd.o, www.x.org, and others) is still having major issues, thanks to the Moin 1.6 upgrade being unbelievably painful; thanks very much to Benjamin Close for somehow dealing with this godawful upgrade, which is running its load average up to 116, and using up to 7GB of RAM just to convert a wiki from Moin 1.5 to 1.6. The snakeoil cert from bugs.fd.o is still vulnerable, and feel free to distrust it just as much as any other snakeoil cert. We'll be getting a real cert from CAcert[2] soonish, but regenerating our snakeoil in the meantime. Thanks for bearing with us; if it's any consolation, it's not been the best week for admins. Cheers, Daniel [0]: http://lists.debian.org/debian-security-announce/2008/msg00152.html [1]: http://www.freedesktop.org/wiki/AccountMaintenance [2]: http://www.cacert.org -- add its certs to your browser if they aren't there, and don't forget to let your distribution and/or browser vendor know. (1 Comment |Comment on this)
Wednesday, March 12th, 2008
4:24 pm	EXA on 965 updates Following on to Carl's update on our LCA talk, I've been trying to pull the 965 Render improvements out of the batchbuffer branch and onto master. Most of the changes in it are not actually dependent on batchbuffers or TTM. We can avoid reuploading programs without TTM. We can make bigger vertex buffers to reduce syncing without TTM. What the TTM branch (intel-batchbuffer) should be getting us is improved EXA pixmap migration performance, reduced memory fragmentation, more efficient buffer reuse, and possibly DRI2. The current status of my work is at git://people.freedesktop.org/~anholt/xf86-video-intel on the 965-render-merge branch. It compiles, it runs, but the output is not quite what I hoped: The code is mostly the same as what's on the branch, with just some changed buffer handling that should be all-or-nothing rendering correctness, not brokenness with colors. If I turn on xcompmgr, that desktop background goes thoroughly flourescent, and the windows partially translucent. Something very weird is going on, and I'm going to take a break and fix my 830/845 Render performance fix ("here test my patch, oh wait I didn't make it compile first") instead of bashing my head against this for now. (5 Comments |Comment on this)
Thursday, September 6th, 2007
1:43 pm	X11R7.3 released X Window System Release 7.3 2007-09-06 The X11R7.3 release incorporates the 1.4 version of the X.Org X Server, which is most notable for the addition of input hotplugging support, with device detection managed either through HAL or a dbus-connected manager. Also new in the X Server since X11R7.2 is the 1.2 version of the RandR extension, which allows for runtime configuration of outputs within X Screens and an improved static configuration system for multihead in a RandR 1.2 environment. This release also rolls in a new driver, xf86-video-vermilion, and re-adds the xf86-video-glide driver which had been present in the monolithic releases. The xbacklight command-line tool is also added for configuring backlight properties through RandR 1.2. Other modules have also gone through the usual host of updates and bugfixes as well. Previous release managers may find me strange, but I didn't mind too much dealing with the release. It was approximately the expected level of stress and frustration. I made some changes this time around which greatly reduced the burden -- the old "branded" tarballs (modulename-X11Rwhatever-version.tar.b2 instead of just modulename-version.tar.bz2) are now a thing of the past, and the published directory structure is simplified. I've update the wiki instructions for the next release manager, and it's relatively short. Basically the only work that's left is what should be left -- making sure all the modules work well together, and making sure the blocker bugs for the server get resolved. As far as that, I think it was a mixed result. Blocker bugs for the server I think I handled reasonably well -- hounding the appropriate people for the critical fixes, and not blocking to deal with the last-minute fixes for minor issues. But the whole-release integration didn't go too well, with at least one required module update having been left out initially (fixed this morning). What I hope we can have happen for the next katamari: I'll tinderbox the proposed module list in our ports tree to shake out integration issues. Module maintainers may update util/modular/module-list.txt to make sure their stuff lands in the next release. (7 Comments |Comment on this)
Saturday, July 21st, 2007
8:16 pm	This GUADEC has been excellent. Not quite the same environment as the last one, since we're hiding in pubs from the rain and general Birmingham dreariness, instead of getting naked in the Mediterranean, but I think the general quality of talks has gone way up. My talk (on gnome-power-manager improvements) seemed to go over pretty well, and discussions with gtk folks were great, particularly at daniels's talk tonight. I finally took the two days needed to sit down and type out the DRM ioctl cleanups I'd committed to do at a conference probably two years ago. I tested it on FreeBSD and it worked great. I passed the branch off to daniels to test, and he said "woo glxgears works. push!". Apparently he was too far gone to notice that DRI hadn't initialized at all, so the linux side of the DRM is totally busted. But hey, it's not like I was more sober, and I wasn't going to turn down pushing +2000, -3000 lines of diff. Now I'm working on fixing up DRM mapping on FreeBSD to be less terrible, and writing some support code in the process that will be important for kernel memory management. (2 Comments |Comment on this)
Friday, March 30th, 2007
1:57 pm	965GM support pushed keithp and I have just pushed the support code for the 965GM (laptop graphics chipset that will be available soon) to mesa, drm, and xf86-video-intel. The remaining piece is agpgart, which we just haven't done the lkml submission for yet, but if you check the patches for those 3 projects, you can probably guess what the agpgart diff looks like. It wouldn't seem like a very big addition, since it was something like 100 lines total, but there's something cool and new here: We've managed to get the ability to push the code before the chipset launch. Previously, chipset support like this has been released early only to distributions, who then try to have packages ready to go for that day (often with bugs or integration issues due to only having received old snapshots), but this still meant that you couldn't just grab a released distro CD and pop it in your machine and go. Now, there's a much better chance of this happening, depending on how your distro's release cycle aligns with ours. Getting even little policy changes like this really gives me hope that we can fix hardware vendors to do the right thing with open source software. Ultimately, it's in their interests. (10 Comments |Comment on this)
Tuesday, February 27th, 2007
4:41 pm	i855 LVDS oops I just found out today that I had totally broken i855 LVDS support in the modesetting branch, and while fixing that, I realized that our i855 LVDS support had been pretty broken since its inception.  With some digging, I found one bugzilla entry for it, but several emails.  Please file more bugzilla entries for bugs, folks, and don't worry about finding the right bug to attach to -- more individual bugs means more a better chance that I'll end up fixing your bug instead of some less important one of someone else's. So, if you're trying to use the modesetting branch on your i855 and having troubles, please try http://people.freedesktop.org/~anholt/i8xx-clocks.diff on your driver from a fresh boot, and either: 1) Tell me that it makes your system work 2) File a bugzilla with Xorg.0.log and a note that you tried this patch. (Comment on this)