Description of problem: I think it's about the time to switch to the SNA architecture. While it might be too big jump to use the SNA as default, it should be at least allowed to enable it in xorg.conf (compiled in). Section "Device" Option "AccelMethod" "SNA" EndSection This architecture gives better 'user experience' the older slow unoptimized UXA (and probably it's also not actively developed anymore) See for details: https://bugs.freedesktop.org/show_bug.cgi?id=49721 Version-Release number of selected component (if applicable): xorg-x11-drv-intel-2.18.0-2.fc18.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: --enable-sna used in .spec file. Additional info:
The existing SNA support is all-or-nothing at compile time, building SNA disables UXA. Given that UXA renders basically correctly while SNA pretty much always has correctness bugs, that's not an acceptable tradeoff. Once upstream fixes that, sure.
Hmm and how about providing intel-sna package - so the user could select whether he prefers UXA or SNA intel driver? I think there are much more unstable packages distributed in rawhide (i.e. whole Gnome3, systemd.... ). I guess the more people will try it - the more bugs could be catched. And while I'm far from saying it a 'very stable driver' - I think it's in the range of 'usable driver' and speed difference especially if the screen handleds more windows is very noticeable.
(In reply to comment #2) > Hmm and how about providing intel-sna package - so the user could select > whether he prefers UXA or SNA intel driver? > > I think there are much more unstable packages distributed in rawhide (i.e. > whole Gnome3, systemd.... ). I'm not going to use the failures of others as an excuse to introduce failings of my own.
I do not think it's about excuses. Every software has bugs - what is the state of development of SNA you would consider as stable?? Do you have any benchmark/test which shows big failures of SNA driver? What has to pass you would conclude it's worth to package it? IMHO I do not see any visual incorrectness with SNA drivers I'm using. unlike with UXA driver I've seen occasionally some weird grey lines in Qt Pidgin application. The other side of story is GPU hang which the SNA driver is able to trigger more often then UXA driver - but that's rather kernel issue. Fedora Rawhide is about experiments - thus I do not see a big problem if user could select from 2 packages - either 'more stable UXA' version (default), or 'more experimental but many times faster' SNA version.
(In reply to comment #4) > Fedora Rawhide is about experiments - thus I do not see a big problem if > user could select from 2 packages - either 'more stable UXA' version > (default), or 'more experimental but many times faster' SNA version. That's an opinion you can hold, but I do have a problem with it. I'm not enabling SNA in Fedora by making two packages, rawhide or not. I made an upstream bug about this for a reason.
Assuming this upstream commit is the step in this direction? http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=e45629135065d0cc73c285f8df35ab4e1d07c6dc
Testing SNA on Fedora 17 ("Mesa DRI Intel(R) 965GM") on the last 24h and everything working fine (was able to see some quick-to-vanish-automatically corruption on Google Chrome once, though). I guess the sensible thing to do, however, would be to enable SNA on F18 builds and then try to get proper testing on Intel test day, no? ( https://fedoraproject.org/wiki/Test_Day:2012-09-20_Intel )
Well, if ajax is open to the possibility of enabling it by default at this point - i.e. if his concerns about upstream code quality have been addressed. If he is still of the firm opinion that the code has known defects too serious to allow it to be used by default, there wouldn't be much benefit from empirical testing.
What are the chances of having SNA in F19 / F20 time-frame?
Replying to comment 9, You can enable SNA by request using a custom file, as detailed in https://wiki.archlinux.org/index.php/Intel_Graphics#Choose_acceleration_method . What won't happen is the maintainer (ajax, I think) enabling SNA by default unless upstream (Intel) does the same. P.S.: beware to not submit bug reports of xorg-x11-drv-intel crashes if you are using SNA, since it is not "supported" by Fedora.
I (somehow) was under the impression I needed to recompile the driver to get SNA working. Gah. Works like a champ, thanks :) - Gilboa
FYI, Arch Linux started using this month SNA by default: https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/xf86-video-intel&id=d03f5fb77df413017821f492aa81e5d68def7e48 . Upstream still uses UXA by default, though, so I am assuming no changes will happen on Fedora side.
A little late to this game - I've been working to fix the power consumption problems on my Thinkpad E430 with f20, and using SNA over UXA was one of the things that helped. I presume this is because of the enhanced offload of operations to dedicated hardware requiring fewer transistors for the same work. Besides better battery, I'm pulling less power from the grid (and prolonging the life of my components by running them at lower heat). Fedora is much more pleasurable to use with SNA (notably Firefox and KDE) but that just benefits us. Multiplying a reduced power draw across the installed base of intel Fedora users could have benefits outside the community as well. I'll go see what the upstream caution is about, but just as far as Fedora is concerned, it would be nice if we had a way for our installed base to not have to choose between using less electricity and being permitted to report issues in a case like this. I realize this is a bigger issue than just this one bug.