Eric Anholt (anholt) wrote,
Eric Anholt

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

  • Post a new comment


    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.