Bug 1992

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.