Bug 820566 - SNA acceleration should be enabled (eventually used as default)
SNA acceleration should be enabled (eventually used as default)
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-10 08:00 EDT by Zdenek Kabelac
Modified: 2014-04-03 11:19 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-23 15:30:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 50290 None None None Never

  None (edit)
Description Zdenek Kabelac 2012-05-10 08:00:31 EDT
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:
Comment 1 Adam Jackson 2012-05-23 15:30:12 EDT
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.
Comment 2 Zdenek Kabelac 2012-05-24 05:07:57 EDT
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.
Comment 3 Adam Jackson 2012-05-24 11:50:24 EDT
(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.
Comment 4 Zdenek Kabelac 2012-05-24 12:02:08 EDT
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.
Comment 5 Adam Jackson 2012-05-24 12:26:15 EDT
(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.
Comment 6 Zdenek Kabelac 2012-05-27 12:15:17 EDT
Assuming this upstream commit is the step in this direction?

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=e45629135065d0cc73c285f8df35ab4e1d07c6dc
Comment 7 Pedro Francisco 2012-07-24 09:58:44 EDT
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 )
Comment 8 Adam Williamson 2012-07-24 14:30:23 EDT
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.
Comment 9 Gilboa Davara 2013-06-12 01:14:50 EDT
What are the chances of having SNA in F19 / F20 time-frame?
Comment 10 Pedro Francisco 2013-06-12 05:25:55 EDT
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.
Comment 11 Gilboa Davara 2013-06-12 07:39:50 EDT
I (somehow) was under the impression I needed to recompile the driver to get SNA working. Gah.
Works like a champ, thanks :)

- Gilboa
Comment 12 Pedro Francisco 2013-08-11 10:33:19 EDT
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.
Comment 13 Bill McGonigle 2014-04-03 11:19:33 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.