git.cworth.org Git - cworth.org/blob - src/intel/driver_stability.mdwn

   1 [[!meta title="On Intel Driver Stability"]]
   2
   3 [[!tag intel]]
   4
   5 It's hard for me to believe that my last technical post on the
   6 progress of the Intel graphics driver was nearly a year
   7 ago. Certainly, a lot has happened in that year, and recent
   8 developments have been covered well by
   9 [Keith](http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/),
  10 [Eric](http://anholt.livejournal.com/41132.html), and
  11 [Jesse](http://virtuousgeek.org/blog/index.php/jbarnes/2009/05/07/pageflipping_blocking_etc). So
  12 I won't go into any of those details, but I do want to give my
  13 impression of where things stand.
  14
  15 As my colleagues have described so well, a major restructuring of the
  16 driver is now complete, (KMS, GEM, dri2, removal of XAA, EXA, dri1,
  17 etc.). This restructuring caused months of upheaval, followed by
  18 months of stabilization during which many bugs were shaken out. The
  19 end result is that the primary developers are all optimistic about the
  20 current state of the driver. Things seem better than ever.
  21
  22 In the meantime, however, it's also obvious that some users are not
  23 happy with the driver, and some have gotten the impression that the
  24 quality is getting consistently worse with time. Some have theorized
  25 that no quality-assurance testing is happening, or that the developers
  26 just plain don't care about regressions. Neither of those theories are
  27 true, so why is there such a disconnect between the developers and the
  28 users?
  29
  30 One reason for unhappy users is the lag between development happening
  31 and users getting their hands on the code. So the phase of upheaval
  32 and instability might be behind the developers, but some users are
  33 just entering into it. This is exacerbated by the fact that the major
  34 restructuring puts several important components of the driver into the
  35 kernel. It used to be that getting the latest Intel driver just meant
  36 updating an xf86-video-intel module or upgrading an
  37 xserver-xorg-video-intel package. But now it's essential to get a
  38 recent kernel as well, (note that almost all of the major fixes that
  39 Eric describes happened in the kernel, not the user-level driver). And
  40 these fixes aren't in a major kernel release until 2.6.30 which
  41 appeared only today.
  42
  43 In addition, distributions and users have a tendency to update the
  44 kernel less frequently than user-level components. So when a user
  45 checks out the latest xf86-video-intel from git, (without a kernel
  46 upgrade), not only is that user not getting the "latest driver" as
  47 recommended by the developers, but they might also be running a
  48 combination that the developers and QA never saw nor tested.
  49
  50 For example, I recently attempted to run the latest-from-git Intel
  51 driver with a kernel version as installed by current Debian
  52 installation CDs.  This kernel is ancient with respect to our driver
  53 development (2.6.25 I think). What I found was that the X server would
  54 not start at all. Obviously, we had neglected to test this particular
  55 combination, (so yes, QA isn't perfect---but it also can't cover the
  56 infinite number of possible combinations).  Fortunately, the fix was
  57 simple, and appears in the 2.7.99.901 snapshot I just released
  58 (today!) so will appear in the 2.8.0 release very soon.
  59
  60 The packagers of X for Ubuntu have been working hard to address this
  61 exact problem of the lag between developers and users. They've setup a
  62 repository of packages named
  63 [xorg-edgers](https://launchpad.net/~xorg-edgers) where users can
  64 easily get packages built directly from git. I don't think it includes
  65 the kernel yet, as it will soon hopefully, but this is definitely a
  66 step in the right direction.
  67
  68 But what about the users that _did_ upgrade their kernel and driver
  69 and are _still_ seeing some major problems? In this case, we really
  70 want to hear from you. We take pride in our work and are committed to
  71 doing our best to make quality releases without regressions. When you
  72 hit some awful behavior, (GPU hang, scrambled mode, abysmal
  73 performance), it may be that you're just hitting a combination of
  74 components or application behavior that we've never seen before. We
  75 want those details and we want to fix the problem. File good [bug
  76 reports](http://intellinuxgraphics.org/how_to_report_bug.html) and
  77 please make use of the "regression" keyword as appropriate. We pay
  78 attention to that.
  79
  80 Performance regressions are an especially important issue. In fact,
  81 performance is so important that I'll make a separate post about
  82 that. I've got some exciting news to share about performance
  83 measurement.