Created attachment 17742 [details] The complete X server configuration A few days ago there was removed the default for hardware acceleration on the X.Org Intel driver = XAA in the OpenSUSE X.Org additional repositories, because it is no longer supported by Intel. The new defaults changed to as follows: Option "AccelMethod" "EXA" Option "ExaNoComposite" "false" Option "MigrationHeuristic" "always" With these settings and according to the package with the latest upstream there xorg-x11-driver-video-7.3-201.1 (last change 14th of July 2008, see http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.0) I get a very bad graphics performance, for instance scrolling in KDE 4.1 Konqueror and Krusader is very slow. On the other hand, changing to Option "MigrationHeuristic" "greedy" destroys my KDE 4.1 systray. I made a bug tracker entry at bugs.kde.org, which they marked as INVALID because it came from the X Server itself: http://bugs.kde.org/show_bug.cgi?id=166827 In the attachment at bugs.kde.org you can see the bad rentering of the KDE 4.1 systray. The only workaround for me is continuing using the "XAA" acceleration, where the performance is fine and the systray looks as expected. Hardware: Intel 865 G TEST 1 - /etc/X11/xorg.conf: added explicit Option "AccelMethod" "EXA" added explicit Option "MigrationHeuristic" "smart" - Restart computer Result: Scrolling in Konqueror is very slow, acceleration possibly doesn't really work, systray in KDE 4.1 works. TEST 2 - /etc/X11/xorg.conf: Left Option "AccelMethod" "EXA" Changed Option "MigrationHeuristic" "greedy" - Restart computer (for being sure to have reinitialized hardware) Result: Scrolling works fluently, acceleration is very good, systray in KDE 4.1 is destroyed as you can see at my KDE bug tracker entry(even the tooltips over the systray seem to open on their right position, but the icons are not really rendered as expected), the rest of KDE 4.1 works fine TEST 3 - /etc/X11/xorg.conf: Changed Option "AccelMethod" "XAA" Commented out #Option "MigrationHeuristic" "greedy" Result: Scrolling works fluently, acceleration is very good, systray in KDE 4.1 works.
Please also attach the full Xorg.0.log. In particular, which version of xserver is this?
Created attachment 17745 [details] Appropriate /var/log/Xorg.0.log $> X -version This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the "xorg" product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. X.Org X Server 1.4.99.905 (1.5.0 RC 5) Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: openSUSE SUSE LINUX Current Operating System: Linux rkrell 2.6.25.9-0.2-default #1 SMP 2008-06-28 00:00:07 +0200 i686 Build Date: 14 July 2008 01:40:14PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present
Created attachment 17746 [details] Appropriate /var/log/Xorg.99.log, which used EXA The previous Xorg.0.log is the last one after returning to XAA, here is one were I tried EXA, I'm not sure whether this was of mentioned TEST 1 or TEST 2. Standing by for providing more details.
I see, the last attachment /var/log/Xorg.99.log was the one started with the defaults from openSuSE 11.0 / SaX2, as there are: Option "AccelMethod" "EXA" Option "ExaNoComposite" "false" Option "MigrationHeuristic" "always" After that, I made changes for testing in /etc/X11.xorg.conf manually.
Created attachment 17818 [details] [review] Make sure exaMigrateTowardFb/Sys end up calling exaCopyDirty I noticed that exaMigrateTowardFb/Sys() don't always end up calling exaCopyDirty(), which is critical now. This patch should fix that, but it doesn't seem to fix "greedy" completely here. It would be much more interesting to identify and fix the performance issues with "always" though.
Thanks, Michel! René, I've updated the sources for xorg-x11-server in our buildservice with Michel's patch. Package is scheduled for rebuilding. Make sure build date is July 22 or later. Please test.
Do you try the latest driver released by Intel Upstream? external downloading http://www.intellinuxgraphics.org/download.html
(In reply to comment #6) > Thanks, Michel! > > René, I've updated the sources for xorg-x11-server in our buildservice with > Michel's patch. Package is scheduled for rebuilding. Make sure build date is > July 22 or later. Please test. > Hi Stefan, thanks and sorry for being so late, I had some holidays. Unfortunately, there is absolutely no change in comparison with what I have reported here, using the latest packages from build service: --- xorg-x11-driver-video-7.3-204.7 xorg-x11-server-7.3-137.1 --- Nothing else than the setting Option "AccelMethod" "XAA" works performantly AND without a broken systray in KDE 4.1 (from KDE 4.1 desktop factory repository).
Created attachment 18102 [details] Xorg.0.log with the optimal acceleration "XAA" at this time for me Only FYI: The log with the current X Server version and XAA acceleration, which is still optimal for me.
Created attachment 18352 [details] Nothing new even with X.Org X Server 1.4.99.906 (1.5.0 RC 6) / Intel video driver 2.4.1 Some intermediate state - still does not work with the latest OpenSUSE X.Org packages from 2008/08/18: xorg-x11-7.3-166.1 xorg-x11-driver-video-7.3-209.2 xorg-x11-server-7.3-142.7 xorg-x11-libs-7.3-78.1 xorg-x11-libX11-7.3-56.1 ... See attached log for details (recorded with "XAA"). Acceleration method "EXA" does not work with any of the following options: #Option "MigrationHeuristic" "always" #Option "MigrationHeuristic" "smart" #Option "MigrationHeuristic" "greedy" with the same effects as initially described.
(In reply to comment #10) > Acceleration method "EXA" does not work with any of the following options: > #Option "MigrationHeuristic" "always" > #Option "MigrationHeuristic" "smart" > #Option "MigrationHeuristic" "greedy" > with the same effects as initially described. So you're saying "always" and "smart" are now showing the same corruption you were originally only seeing with "greedy"? Weird, did you verify the option is taking effect at all?
(In reply to comment #11) > (In reply to comment #10) > > Acceleration method "EXA" does not work with any of the following options: > > #Option "MigrationHeuristic" "always" > > #Option "MigrationHeuristic" "smart" > > #Option "MigrationHeuristic" "greedy" > > with the same effects as initially described. > > So you're saying "always" and "smart" are now showing the same corruption you > were originally only seeing with "greedy"? Weird, did you verify the option is > taking effect at all? > No, what I'm saying is that each option itself shows the same wrong behaviour as initially described in this thread, of course each of them with some difference compared to the other. I really tried each of them and did a KDE "Logout" which usually restarts the X Server. The X server restart was really goof to see, because there is additionally some flickering and some moment of "uninitialized" screen here with "always" and "smart" Do I have to post logs for starting with each of the EXA options here? I left this out for not overloading this thread with information, and put only one log for you to see the version information. What more information could be useful for you to be analysed? Do you mean EXA should actually work on the mentioned chipset?
Created attachment 18565 [details] The packed xorg.conf / Xorg.0.log for XAA / EXA always / EXA smart / EXA greedy I made another X Server update from the OpenSUSE repositories to the following packages: - Mesa-7.1-30.1 - xorg-x11-7.3-167.3 - xorg-x11-driver-video-7.3-213.3 - xorg-x11-libs-7.3-78.3 - xorg-x11-server-7.3-155.1 and others. The changelog of xorg-x11-driver-video-7.3-213.3 shows among others: --------------- Tue 26 Aug 2008 02:00:00 PM CEST sndirsch@suse.de - xf86-video-intel 2.4.97.0 "[...] first 2.5.0 test release. Should be about as stable as the 2.4.1 and upcoming 2.4.2 releases, but also includes GEM and kernel mode setting code. We haven't pushed the video tearing fixes yet, hopefully that'll be upstream for the next test release. Carl has made good progress on improving EXA performance, but I think the scrolling case may still be sub-par, but we're interested in getting feedback there. [...]" --------------- Not only following the request for feedback I retested XAA and EXA again with the following results (see the attached files for details, reference system OpenSUSE 11.0 with the latest online updates): - XAA no flickering on start systray ok scrolling acceleration fast as in Konqueror 4.1 as in Firefox 3.0.1 still the reference for me and working best - EXA "greedy" no flickering on start systray broken Konqueror 4.1 scrolling fastest of EXA, quite good Firefox scrolling fast - sufficient - EXA "smart" X starts with flickering and uninitialized display buffer for a second Konqueror 4.1 scrolling a bit faster than "always", but insufficient Firefox scrolling fast - sufficient - EXA "always" X starts with flickering and uninitialized display buffer for a second Konqueror 4.1 scrolling slow - insufficient Firefox scrolling middle/slowest of EXA - but sufficient I hope that was helpful for some guys of you. René
Rene, Intel developers support the default setting: EXA + "MigrationHeuristic" "always". Could you file a bug specifically against that configuration, under component "Driver/intel"? I just want to have one issue per bug so we can better track it. Thanks.
(In reply to comment #14) > Rene, Intel developers support the default setting: EXA + "MigrationHeuristic" > "always". > Could you file a bug specifically against that configuration, under component > "Driver/intel"? I just want to have one issue per bug so we can better track > it. Thanks. > Hi Gordon, at first, I re-assign this bug under Driver/intel, for not loosing the history. Meanwhile I got X.org 7.4, I will soon provide new test results only for EXA "always" with the latest components and forget about the other MigrationHeuristics variants to save time and for you meaningless information. Would this be ok for you and the other guys? Otherwise I will assign it back to the category before this...
Created attachment 18915 [details] The Xorg.0.log with server 7.4 and Intel video driver 2.4.97 using EXA "always" I made new tests using only the configuration supported by Intel developers: Acceleration method: EXA Migration heuristic: always The server log you can find in attachment. Scrolling is still very slow and stucking in KDE 4.1.1 applications, as: - Konqueror 4.1.1 (after waiting until the test site was downloaded completely) - KMail - ... Scrolling in Firefox 3.0.1 is slightly faster and more fluent compared to the KDE applications, but still slow.
(In reply to comment #15) > Hi Gordon, at first, I re-assign this bug under Driver/intel, for not loosing > the history. Frankly speaking, I'm afraid Intel upstream developers don't have much interest to the history especially those not related to "always". > Meanwhile I got X.org 7.4, I will soon provide new test results only for EXA > "always" with the latest components and forget about the other > MigrationHeuristics variants to save time and for you meaningless information. > > Would this be ok for you and the other guys? Otherwise I will assign it back to > the category before this... So I really appreciate if we would have a clean bug for tracking.
Ok, I will do this.
> > So I really appreciate if we would have a clean bug for tracking. > Here you are: http://bugs.freedesktop.org/show_bug.cgi?id=17605
*** Bug 17641 has been marked as a duplicate of this bug. ***
I think we can close this one, since greedy is apparently nothing anyone wants to support. Bad performance with always was handled in a seperate bugreport, right? ==> WONTFIX
*** Bug 19059 has been marked as a duplicate of this bug. ***
Hi, I'm not a specialist on all those things, so maybe my post would not be technically correct. Sorry for that. I just wanted to ask some questions. 1. >>I'm afraid Intel upstream developers don't have much interest >>to the history especially those not related to "always". Who are those Intel developers and how can I submit bug to them / contact them? 2. >>I think we can close this one, since greedy is apparently nothing anyone wants >>to support. >> ==> WONTFIX Well, I supposed bug is resolved as WONTFIX only then when there is another solution which allows to cope with introduced artifacts not worsening the other factors i.e. perfomance. Which is not the case here. Am I right? If the developers just don't want to fix the bug or they don't know how to fix it that's not the reason to resolve it as WONTFIX. So why not keep this bug opened, maybe there will be somebody willing to fix it? Regards.
Dear developers, can you please answer why nobody is trying to fix this bug? It's irritating me very much :( I don't want to buy new video card! I dont know anything about video drivers, but I'm willing to spend some time to fix this issue.. if there is somebody who can give me some hints. Hope somebody will answer.
Try kernel >= 2.6.31.3, xorg-server 1.6.5 and the Intel video driver 2.8.99.902 based on UXA. I didn't either buy a new graphics chipset, which works fine for me, so the second way around WONTFIX is finally given :-)
Won't be fixed unless someone shows up with an interest in fixing issues with non-default values of Option "MigrationHeuristic".
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.