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).
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.
What monitor are you using?
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.
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.
Tried it. Had no effect.
please attach your X log and xorg.conf.
Created attachment 3593 [details] xorg.conf
Created attachment 3594 [details] Xorg.log
Still the same with a 6.9/7.0 RC or CVS snapshot?
Afraid so. :(
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?
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.
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.
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.
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.
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 that.
I normally run 1600x1200@85 + 1280x960@85. To make the problem completely go away I can do either: * 1600x1200@60 + 1280x960@60 or * 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?
(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.
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 + 1600x1200@75). 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?
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.
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.
Sometimes I just love you guys ;) The patch makes the problem go almost completely away, even at the highest resolution/frequency. Very nice work. :)
Has/Should this patch be merged to mainline?
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?
(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.
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?
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.
Patch committed to xf86-video-ati HEAD.
Michel, should this bug be closed or do you want to keep it open for some reason?
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.
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.