This seems to be a common problem. I had to downgrade to 2.14.0; some bug introduced in 2.14.903 and still present in 2.15.0 break it thoroughly. Fast is nice, but stable is better.
I agree. The graphics system is basically the only part where I'm envious of windows users. As far as I know, since vista the graphics driver can crash without tearing down the rest of the graphical system, i. e. no data loss.
These bugs range in severity from "inkscape becoming the default PDF viewer" to "file conflict prevents installing a package" to "libc6 lacks the /lib64 symlink and now no dynamically linked programs on the system can run", and everything in between. Fortunately, the "break the whole system" bugs don't happen often, but still: don't run sid unless you want to help filter out breakage for others by hitting it yourself.
In the mean time, back when I used to live with someone who used Ubuntu as his main system, and when I used to run Ubuntu on my laptop, I had to fix system-crippling bugs at least 3 times.
So, anecdotally, I've had less system-killing problems with Sid than Ubuntu's stable releases.
I've never quite understood people who are running Debian on desktop...
However, I treat Squeeze more as a base to build on than as a complete system. For instance, I work with Ruby via rvm, not native, and use a Firefox Nightly build. In that sense it makes a rock-solid foundation: anything that I'm not responsible for, works. Anything I am responsible for is my call, and can't break the underlying system unless I try quite hard.
I suspect some of this is a side effect of the popularity of GPGPU computing. If they don't want their lunch eaten by NVidia and ATI/AMD on certain computational benchmarks, they're going to have to provide a professional implementation of OpenCL on Linux. I suspect (am hoping) that the OpenGL acceleration and plain X11 improvements come as part of the package.
People don't use Windows-only hardware in their supercomputers. NVidia was the first to realize this and this is one reason they have much of the GPGPU mindshare.
Second, the guy that wrote this code, Chris Wilson, is one of the big guys behind Cairo and had an experiment, cairo-drm, where he plugged Cairo directly to an Intel graphics chipset by talking directly to the kernel and bypassing the Intel X drivers. His results were probably the foundation of this new work, as far as I can guess.
I didn't know about Wilson. I'd somehow gotten the impression that this work had been supported by Intel. Oh well. If they didn't, they shoulda. :-)
we can take advantage of additional efficiencies, such as relative relocations, that have been incorporated into recent hardware advances. However, even older hardware performs better from avoiding the implicit context switches and from the batching efficiency of the 3D pipeline...
excellent news then :)
bisecting only makes sense when it's modifications to existing code that can be applied independently.
This is not considered stable but works OK for me. Read the pages first.
EDIT: and its back again. lol.
This commit speeds up general desktop rendering, in both general and pathological cases, for nearly all Intel graphics chipsets, causing everything to feel snappier and more responsive. It's a universally Good Thing.