Bug 20236 - font corruption with latest git
Summary: font corruption with latest git
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-20 09:51 UTC by Andy Furniss
Modified: 2009-05-13 04:23 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
screen 1 showing corruption (57.41 KB, image/png)
2009-02-21 08:39 UTC, Andy Furniss
no flags Details
screen 2 matacity menu corruption (31.96 KB, image/png)
2009-02-21 08:43 UTC, Andy Furniss
no flags Details

Description Andy Furniss 2009-02-20 09:51:04 UTC
Testing R6xxR7xx accel branches on radeon/radeonhd + latest xorg git I am seeing font corruption in seamonkey.

Git bisect came up with

b2ceea3635ec05dca9d4aa2f823b96ae9fce7fe8 is first bad commit
commit b2ceea3635ec05dca9d4aa2f823b96ae9fce7fe8
Author: Maarten Maathuis <madman2003@gmail.com>
Date:   Tue Feb 17 19:40:59 2009 +0100

    Revert "exa: the extent of the valid region is probably much larger than that of the pending damage."
    
    This reverts commit 97c1cbc70216366e92b9371de608ce94e60aa874.
    
    - Sorry for the thinko, pending damage is often not fragmentated.
    - Should the dst region become fragmentated, you actually want to copy more to unfragmentate it.
Comment 1 Michel Dänzer 2009-02-20 10:12:25 UTC
Weird then that it isn't broken with 97c1cbc70216366e92b9371de608ce94e60aa874 already... Does current Git work with 3175646b10c602d17d5dd37bdace7c1c7ee92b3d reverted?
Comment 2 Andy Furniss 2009-02-20 13:24:00 UTC
(In reply to comment #1)
> Weird then that it isn't broken with 97c1cbc70216366e92b9371de608ce94e60aa874
> already... Does current Git work with 3175646b10c602d17d5dd37bdace7c1c7ee92b3d
> reverted?
> 

No, I get corruption with master + above reverted.
Comment 3 Andy Furniss 2009-02-20 14:08:56 UTC
> No, I get corruption with master + above reverted.

If I then revert my revert and

git revert b2ceea3635ec05dca9d4aa2f823b96ae9fce7fe8

It works OK.

Comment 4 Michel Dänzer 2009-02-21 02:48:00 UTC
Reiterating on my doubt from comment #1:

When you bisected to find b2ceea3635ec05dca9d4aa2f823b96ae9fce7fe8 as the culprit, you tried 97c1cbc70216366e92b9371de608ce94e60aa874 and it didn't show the problem?

Could it be the same as bug 16416? Are you using the GTK1 version of seamonkey? Does Option "ExaOptimizeMigration" "off" work around the problem? If it's not the same, please attach a screenshot of the corruption.
Comment 5 Andy Furniss 2009-02-21 08:39:36 UTC
Created attachment 23162 [details]
screen 1 showing corruption
Comment 6 Andy Furniss 2009-02-21 08:40:47 UTC
(In reply to comment #4)
> Reiterating on my doubt from comment #1:
> 
> When you bisected to find b2ceea3635ec05dca9d4aa2f823b96ae9fce7fe8 as the
> culprit, you tried 97c1cbc70216366e92b9371de608ce94e60aa874 and it didn't show
> the problem?

I think the final test was the commit after that - so possibly not tested.
I will try later/tomorrow as I will be away fron PC for a while.
 
> Could it be the same as bug 16416?

Doesn't look the same.

> Are you using the GTK1 version of seamonkey?

No.

> Does Option "ExaOptimizeMigration" "off" work around the problem?

Yes.

> If it's not the same, please attach a screenshot of the corruption.

Uploaded a couple - the corruption is not consistent eg. in screen 1 after alt tab to another browser window and browsing around (I can't clear it by just changing away and back) Your and Alex's names were OK but the number 2 was corrupt every where it appeared.

I don't have much installed on this partition to test with, but it seems that only proportional fonts are affected.

The second screen shows a non seamonkey occurance, the t on the metacity menu are corrupt - later in the same session they rendered properly.

Comment 7 Andy Furniss 2009-02-21 08:43:17 UTC
Created attachment 23163 [details]
screen 2 matacity menu corruption
Comment 8 Michel Dänzer 2009-02-21 11:09:56 UTC
I suspect this is a driver coherency issue - does

Option "ExaNoDownloadFromScreen"

or

Option "ExaNoUploadToScreen"

work around the problem? (Without the previous workaround)
Comment 9 Andy Furniss 2009-02-22 06:37:05 UTC
(In reply to comment #8)
> I suspect this is a driver coherency issue - does
> 
> Option "ExaNoDownloadFromScreen"

This fixes it.

> Option "ExaNoUploadToScreen"

Does not fix. 

Thinking I had fount the guilty commit I didn't give hardware details in the origional report :-( 

I don't know if it's relavent but this is an AGP card.
Comment 10 Andy Furniss 2009-02-22 10:58:35 UTC
As for the other test, I did a

git reset --hard 97c1cbc70216366e92b9371de608ce94e60aa874

Applied b349a764e98f0d8f221190157ffa0904b91beca5 to fix the build

I see no corruption.

Comment 11 Michel Dänzer 2009-02-23 01:21:57 UTC
(In reply to comment #10)
> As for the other test, I did a
> 
> git reset --hard 97c1cbc70216366e92b9371de608ce94e60aa874

Ugh sorry, I meant to say 736b6fbd2c941b6276066cd1503523edebe7bf3d all along.
Comment 12 Michel Dänzer 2009-02-23 01:28:31 UTC
(In reply to comment #9)
> > I suspect this is a driver coherency issue - does
> > 
> > Option "ExaNoDownloadFromScreen"
> 
> This fixes it.

[...]

> I don't know if it's relavent but this is an AGP card.

Accelerated DownloadFromScreen is indeed known to be unreliable on some AGP setups, which is why the driver option "AccelDFS" defaults to off. It looks like this logic isn't hooked up for R6/700 yet though.

Anyway I think things are pointing to the driver, reassigning.
Comment 13 Andy Furniss 2009-02-23 04:50:55 UTC
(In reply to comment #11)

> Ugh sorry, I meant to say 736b6fbd2c941b6276066cd1503523edebe7bf3d all along.
 
I reset to this and was about to post that there was no corruption when I noticed one char and that's mended it's self now, so it's there but something like 200X less obvious/ takes a lot longer to appear.

FWIW running with this commit is really slow for scrolling/drawing browser pages - I had to treble check I wasn't running with something disabled.

  
Comment 14 Andy Furniss 2009-02-23 04:53:37 UTC
(In reply to comment #12)

 
> Anyway I think things are pointing to the driver, reassigning.

OK, but I've been testing with radeonhd - although I did try radeon when I first noticed the problem and it was affected aswell.

 

Comment 15 Michel Dänzer 2009-02-24 08:39:48 UTC
(In reply to comment #14)
> OK, but I've been testing with radeonhd - although I did try radeon when I
> first noticed the problem and it was affected aswell.

Feel free to reassign (with the 'Reassign bug to default assignee and QA contact, and add Default CC of selected component' radio button selected) or file another bug against the radeonhd driver.
Comment 16 Andy Furniss 2009-03-02 07:31:40 UTC
(In reply to comment #15)

> Feel free to reassign (with the 'Reassign bug to default assignee and QA
> contact, and add Default CC of selected component' radio button selected) or
> file another bug against the radeonhd driver.
> 

I'll leave it as radeon for now - I've tested the latest and it's the same.

I rechecked that reverting b2ceea3635ec05dca9d4aa2f823b96ae9fce7fe8 really does fix it and it does - I accept it may be luck, but two days and I didn't see any font corruption.

After lots of trying I only found one other case of a transparent png over a repeating .jpg that I could get to corrupt and I had to scroll the page really fast so it couldn't keep up to get that to happen and it was minor and cleared quickly.

Running with ExaNoDownloadFromScreen off seemed quite slow in some circumstances.

 
Comment 17 Andy Furniss 2009-03-03 10:02:16 UTC
(In reply to comment #16)

> Running with ExaNoDownloadFromScreen off seemed quite slow in some
> circumstances.

I don't know if this is relevant, but while testing for another bug - 20436, it was found that 
Option "BusType" "PCIE"
fixed it.

It does not fix this one though - if anything it makes it twice as bad.

Comment 18 Alex Deucher 2009-03-18 11:16:48 UTC
I've disabled gart transfers on r6xx/r7xx AGP cards:
c0e2513ab128ddd5be0ed626d9e31777a98983ef
Comment 19 Andy Furniss 2009-03-19 05:52:31 UTC
(In reply to comment #18)
> I've disabled gart transfers on r6xx/r7xx AGP cards:
> c0e2513ab128ddd5be0ed626d9e31777a98983ef
> 

This fixes it for ati, but the similar patch for radeonhd does not fix the same
issue with that driver.
Comment 20 Alex Deucher 2009-03-19 07:57:13 UTC
(In reply to comment #19)
> This fixes it for ati, but the similar patch for radeonhd does not fix the same
> issue with that driver.
> 

fixed now.
Comment 21 Andy Furniss 2009-03-23 08:31:21 UTC
(In reply to comment #18)
> I've disabled gart transfers on r6xx/r7xx AGP cards:
> c0e2513ab128ddd5be0ed626d9e31777a98983ef
> 

I've noticed that although this fixes the issues with ati some web pages with seamonkey take far too long to render and scroll very poorly (smooth scroll is off).

An example page is 
http://redbutton.svn.sourceforge.net/viewvc/redbutton/redbutton-browser/trunk/

I can scroll OK as fast as I can go with the mouse wheel, but as soon as I use the scroll bar to get to the bottom quickly it pauses and takes a while to render, then pause again, renders ... until I get to the bottom.

Switching metacity work spaces to (and from partially) is also very slow.
At 1024x768 it takes a second to render the screen and a further second for the contents of the previous workspace to be cleared. At high res it's 3+3 seconds and  when switching away from that workspace it still delays the metacity graphic that shows which workspace you are on from being cleared.

These issues do not happen if I use xorg vesa driver (which FWIW currently doesn't manage to set up mtrr for me).

Top shows CPU being eaten by Xorg, oprofile shows libc memcopy.
Comment 22 Michel Dänzer 2009-05-09 09:45:58 UTC
Are you still seeing the font corruption? If not, please resolve this report as fixed and track other issues in other reports, be it existing ones or new ones.


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.