Bug 16773

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. ***

*** 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".