Intel significantly speeds up graphics under Linux (X.org)(cgit.freedesktop.org)
cgit.freedesktop.org
Intel significantly speeds up graphics under Linux (X.org)
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=bcef98af561939aa48d9236b2dfa2c5626adf4cb
52 comments
This is great. Now if only the newer Intel drivers didn't make X segfault!
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.
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.
> 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.
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.
Well, on the other hand, nVidias drivers were responsible for 30% of Vista crashes..
Modern distributions are unusable for me because of Intel 855GM graphics driver bugs. The latest one I can use is Ubuntu 10.10 with special patches by glasen-hardt.de, even Fedora 15 and openSUSE 11.4 give me trouble with flashing windows, missing content etc.
Yeah, I have an old lightweight Sony with 852/855 and it ran better with Gentoo five years ago than with Maverick today. To get it to work Ubuntu turns off the acceleration so it feels so damn slow. Crossing my fingers.
The worst part is the intel people have been talking about just dropping support for older chips altogether.
So, as a Debian User, I can have use of this in 5 years.
Or run Debian Sid, as you ought to on the desktop ;).
Debian testing would make a much better choice on the desktop for anyone not actively trying to help Debian development by trying bleeding-edge packages and filing bugs. Run Debian sid if you don't mind encountering breakage and filing bugs, for the benefit of the users of testing who then won't have to deal with the buggy packages you did. :)
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.
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.
True.
The new intel drivers compiles fine with Sid, while not with Squeeze.
Will test tonite. Regards.
Still more stable than half the other distributions out there
[citation needed]
generally people who say this haven't actually tried sid or "other distributions"
I know that the plural of anecdotes is not data, but I currently run Sid, and I have been for several years. It hasn't been problem free, but I don't recall a system-killing update. The most common problem is some missing or broken dependencies for a package forcing me to hold off installing a package or updating my system for a few days.
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.
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.
When it comes to system-killing bugs, it also matters whether you update daily or less often; system-killing bugs often get reported right after a mirror pulse and fixed one or two mirror pulses later (less than a day).
Yes, right about when Debian will finally update to Firefox 3.6.
I've never quite understood people who are running Debian on desktop...
I've never quite understood people who are running Debian on desktop...
Not everyone cares about having the latest bits. Sometimes, you want a system which you don't have to upgrade or fiddle with frequently. And yes, that can include desktop systems, particularly desktop systems other than your own. :)
Giving these "not your own" desktop systems an old, slow, and out-of-support web browser doesn't seem like a favor....
I run Debian Squeeze on the desktop because I have jobs I want that desktop to do for me, without my having to worry about it unexpectedly not being able to do them.
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.
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'm struggling to understand what this means from the description, anyone mind decoding for me?
FWIU, this new architecture makes most of 2D acceleration go through the 3D pipeline, saving a lot of overhead from switching between the two current "rings" (BLT for 2D and RENDER for 3D).
It's nice to see Intel cares about their X support now.
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.
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.
I am skeptical of this, for two reasons. First, the GPGPU thing really hasn't affected Intel, who still sells more units than either AMD or nVidia, and will probably continue to have a stranglehold on their current markets. GPGPU really doesn't matter to most people.
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.
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.
Intel has been trying to get into the GPGPU business for years. The problem for them, of course, is you have to have a credible GPU before you can GP with it. Here's where they tried to glue together a bunch of existing cores (yes P54C Pentiums) and call it a GPU: http://en.wikipedia.org/wiki/Larrabee_%28microarchitecture%2... Like early experiments in aviation, it didn't fly.
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. :-)
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. :-)
Intel hired Chris a couple years ago, and he has been doing awesome things ever since. Like this SNA thing. :3
Intel has cared about X for a long time. They have employed Keith Packard (X.org project lead) since 2006.
I probably didn't follow correctly, but doesn't this only affect Sandy Bridge processors?
Nope:
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...
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...
[deleted]
My current laptop is a Dell C510 running Arch Linux, rocking a massive 384MB of RAM and LXDE. It's relatively (surprisingly) snappy as is, but any improvement is going to make a huge difference. Great work.
Scratch that, apparently I've got an ATI Radeon Mobility in this thing. Regardless, still an excellent update.
could someone point to a source identifying the different generations of chipset referred to in the test? (gen3, gen4, etc.)
I like the size of this commit! Makes bisecting all so easy!
The arguments against large commit size do not hold in this case. If you look at it, the patch consists of a few changes to Makefile.am, configure.ac, man/intel.man, src/Makefile.am, and src/intel_module.c, which contain no significant logic, and completely new files in the directories src/sna/ and test/. It's one new feature that is practically self-contained, so I don't see any sense in splitting it up into smaller commits.
Sounds reasonable.
if it's new code, you can't bisect. think about it - you need all the new code to compile. if you only had half, it wouldn't compile.
bisecting only makes sense when it's modifications to existing code that can be applied independently.
bisecting only makes sense when it's modifications to existing code that can be applied independently.
Be careful with sarcasm around here.
Any way to get this in Ubuntu soon?
For anyone interested add these PPAs:
https://launchpad.net/~xorg-edgers/+archive/ppa https://launchpad.net/~sarvatt/+archive/intel-sna
This is not considered stable but works OK for me. Read the pages first.
https://launchpad.net/~xorg-edgers/+archive/ppa https://launchpad.net/~sarvatt/+archive/intel-sna
This is not considered stable but works OK for me. Read the pages first.
Link broken? update: working now?
It'd be more useful if it had a list of hardware expected to improve with this patch.
The link's now broken?
For non-X people (IOW, everybody except me and Josh):
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.
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.