Bug 1992 - [ATI/radeon] timing bug (tearing)
Summary: [ATI/radeon] timing bug (tearing)
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 6.8.1
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Xorg Project Team
QA Contact:
Keywords: patch
Depends on:
Reported: 2004-12-02 09:22 UTC by Pierre Ossman
Modified: 2007-02-22 14:27 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

Photo of effect (56.55 KB, image/jpeg)
2004-12-02 09:26 UTC, Pierre Ossman
no flags Details
xorg.conf (3.39 KB, text/plain)
2005-10-20 12:10 UTC, Pierre Ossman
no flags Details
Xorg.log (70.27 KB, text/plain)
2005-10-20 12:10 UTC, Pierre Ossman
no flags Details
Attempt to fix some R300 family oddities in the handling of Option "DisplayPriority" "HIGH" (1.91 KB, patch)
2006-03-19 01:56 UTC, Michel Dänzer
no flags Details | Splinter Review

Description Pierre Ossman 2004-12-02 09:22:19 UTC
FC3 with Xorg 6.8.1. Radeon 9700.

This problem has plagued me for as long as I've been running Linux with this
graphics card. (XFree 4.3.0, xorg 6.7.0 and xorg 6.8.1).

Whenever there is a lot of display activity I get junk all over the screen. This
seems to be related to how the hardware is handled since I cannot do a screen
shot of the effect. Basically it smears out random stuff from the screen over
random portions. The "randomness" in this changes constantly so it appears more
or less like static over the screen.

Scrolling or dragging large windows will cause this effect.
Video will cause this effect to the extreme. The smaller I make the video window
the more of this effect shows up. Above a certain size the effect stops. The
higher resolution of the movie, the more problems (and larger threshold size).
Comment 1 Pierre Ossman 2004-12-02 09:26:28 UTC
Created attachment 1443 [details]
Photo of effect

Attempt at photo of the bug. Compressed to ease load on bugzilla servers. More
pictures at better quality can be provided if needed.
Comment 2 T. Hood 2005-09-23 09:50:47 UTC
What monitor are you using?
Comment 3 Pierre Ossman 2005-09-24 02:07:21 UTC
I've tried it with a LG Studiowork 995E and a HP P1110, both CRT. I'm afraid I
don't have a TFT to try it with.
Comment 4 T. Hood 2005-10-05 03:16:17 UTC
radeon(4x) says:

       Option "DisplayPriority" "string"
              Used  to prevent flickering or tearing problem caused by display
              buffer underflow.
              AUTO   -- Driver calculated (default).
              BIOS   -- Remain unchanged from BIOS setting.
                        Use this if the calculation is not correct
                        for your card.
              HIGH   -- Force to the highest priority.
                        Use this if you have problem with above options.
                        This may affect performence slightly.
              The default value is AUTO.

I don't know whether or not this is relevant.
Comment 5 Pierre Ossman 2005-10-05 04:06:40 UTC
Tried it. Had no effect.
Comment 6 Adam Jackson 2005-10-20 08:17:53 UTC
please attach your X log and xorg.conf.
Comment 7 Pierre Ossman 2005-10-20 12:10:05 UTC
Created attachment 3593 [details]
Comment 8 Pierre Ossman 2005-10-20 12:10:39 UTC
Created attachment 3594 [details]
Comment 9 Michel Dänzer 2005-11-08 07:23:10 UTC
Still the same with a 6.9/7.0 RC or CVS snapshot?
Comment 10 Pierre Ossman 2005-11-08 07:25:54 UTC
Afraid so. :(
Comment 11 Erik Andren 2006-03-15 04:43:13 UTC
Does it work without problems in another OS or with the fglrx-drivers?
Can you 100% rule out that this is isn't an hardware error?
Are there any improvements with a current xorg release?
Comment 12 Pierre Ossman 2006-03-15 07:31:29 UTC
One can never be 100% sure since other OS/drivers might access the hw in ways
that doesn't trigger the bug.

But it does work fine in Windows (XP). I've also tried two separate (although
identical) cards, both with the same result.

I haven't used the fglrx driver at all since it didn't have decent multi-head
support (or at least didn't have the last time I had a look).

The different xorg version hasn't affected the issue at all, neither for worse
or for better.
Comment 13 Michel Dänzer 2006-03-16 20:16:33 UTC
Does it also happen at lower resolutions and/or refresh rates? I guess you may
just be pushing the memory bandwidth a little too high.
Comment 14 Pierre Ossman 2006-03-17 00:06:59 UTC
Disabling multi-head makes the problem less frequent, but it's still there. I
can try changing resolution and frequency when I get back home tonight.

Still, if memory bandwidth is the problem, it should be possible to throttle or
rearrange the accesses to work around the problem. After all, I haven't been
able to provoke the problem in Windows no matter how much I try.
Comment 15 Pierre Ossman 2006-03-17 06:44:06 UTC
Confirmed. Lowering the resolution or refresh rate makes it impossible to
produce the problem. But I have to go down to low levels so it isn't really a
viable solution.
Comment 16 Michel Dänzer 2006-03-18 04:26:33 UTC
How low do you have to go? Does Option "DisplayPriority" have any influence on
how low?

Re: comment #14: The Windows driver has sophisticated bandwidth management,
whereas we have basically none yet. This bug might be considered a wishlist for
Comment 17 Pierre Ossman 2006-03-18 04:37:27 UTC
I normally run 1600x1200@85 + 1280x960@85. To make the problem completely go
away I can do either:

 * 1600x1200@60 + 1280x960@60


 * 1280x1024@85

I.e. either run at the 60 Hz and feel your retinas detach, or disable multi-head
and run at a rather reduced desktop size.

I'll see if I can get both screens to 75 Hz (same res.) and see if
DisplayPriority can solve the issue. Do I need a fresh boot for "BIOS" mode to work?
Comment 18 Michel Dänzer 2006-03-18 05:14:38 UTC
(In reply to comment #17)
> I.e. either run at the 60 Hz and feel your retinas detach, or disable multi-head
> and run at a rather reduced desktop size.

It seems odd that you'd have to go that low with single head; make sure the
second CRTC is really disabled.

> Do I need a fresh boot for "BIOS" mode to work?

You shouldn't... "HIGH" should reserve as much bandwidth as possible for the
display(s) in theory.
Comment 19 Pierre Ossman 2006-03-18 05:44:20 UTC
Back from testville. I managed to get the combination 1600x1200@75 +
1280x1024@60. At that rate I could still see tearing. When using "BIOS"-mode the
least ammount of tears appeared, "HIGH" was the worst (I was even able to get
tearing on an idle screen when I cranked up the displays to 1600x1200@85 +

In "HIGH" mode you could clearly see that the RAMDAC ran out of bandwidth. There
was a constant shift rightwards after the drawing had hit the overlay area.
Moving the overlay around also moved the start of the tear.

Isn't there a slight pause during the horisontal sweep that should allow the
RAMDAC to close any gap that might have occured?
Comment 20 Pierre Ossman 2006-03-18 05:49:17 UTC
Ehm... I take part of that back :)

There was an increasing shift. I.e. the shift increased a bit to the right by
each scan line. The increase was constant though.
Comment 21 Michel Dänzer 2006-03-19 01:56:32 UTC
Created attachment 4988 [details] [review]
Attempt to fix some R300 family oddities in the handling of Option "DisplayPriority" "HIGH"

Does this patch make a difference with Option "DisplayPriority" "HIGH"? If it
doesn't, please attach a new logfile.
Comment 22 Pierre Ossman 2006-03-19 11:30:55 UTC
Sometimes I just love you guys ;)

The patch makes the problem go almost completely away, even at the highest
resolution/frequency. Very nice work. :)
Comment 23 Erik Andren 2006-04-12 06:50:38 UTC
Has/Should this patch be merged to mainline?
Comment 24 Pierre Ossman 2006-04-27 21:53:17 UTC
I would vote for it to go mainline. I'd still like to see a bit more improvement
until I consider the bug closed though.

Is NEEDINFO really correct right now?
Comment 25 Michel Dänzer 2006-04-27 22:48:33 UTC
(In reply to comment #24)
> I would vote for it to go mainline. 

Yeah, sorry I still haven't got around to committing this, hopefully soon.

> I'd still like to see a bit more improvement until I consider the bug closed
> though.
> Is NEEDINFO really correct right now?

I'm afraid so; I'm not sure what the cause of the remaining problem(s) is.
Comment 26 Pierre Ossman 2006-04-28 03:58:35 UTC
I though it was determined that this is a bandwidth issue, and that to properly
fix it we need more advanced bandwidth management in the driver?
Comment 27 Michel Dänzer 2006-04-28 15:38:55 UTC
Yeah, but this mechanism to control the assignment of bandwidth is now fully
utilized, and I'm not sure there is another mechanism short of limiting modes.
Comment 28 Michel Dänzer 2006-04-30 07:32:16 UTC
Patch committed to xf86-video-ati HEAD.
Comment 29 Erik Andren 2006-05-10 06:20:37 UTC
Michel, should this bug be closed or do you want to keep it open for some reason?
Comment 30 Michel Dänzer 2006-05-10 16:21:12 UTC
Not sure... the Pierre says he's still seeing artifacts, so it doesn't seem
'fixed' per se, but I don't have any good ideas for further improvement ATM.

PS: No need to CC me, I read the xorg-team list.
Comment 31 Timo Jyrinki 2007-02-22 14:27:24 UTC
Marking broken (status null/blank) bugs in xorg with no activity in a long time as fixed. Please reopen if you think it's necessary, but first do a search if a similar bug report is already filed and in a NEW/ASSIGNED state. These bugs do not currently show in most search results as they do not have any status.

Sorry for this janitorial spam, you know where to send hate mails to when your inbox gets full of bugs you're subscribed to.

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.