Bug 28960 - Screen tearing (some tiles rendered with offset) especially when scrolling etc. in DualHead mode on HD4350
Summary: Screen tearing (some tiles rendered with offset) especially when scrolling et...
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-08 03:15 UTC by Grzegorz Wierzowiecki
Modified: 2019-11-19 07:29 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Screenshot: Dolphin as should be.png (122.52 KB, image/png)
2010-07-08 11:45 UTC, Grzegorz Wierzowiecki
no flags Details
Screenshot: Dolphin after moving around from one to another desktop.png (109.87 KB, image/png)
2010-07-08 11:46 UTC, Grzegorz Wierzowiecki
no flags Details
Xorg log with "Option "AccelDFS" "off" " , what means to me : properly with very slow performance (97.24 KB, text/plain)
2010-07-08 13:31 UTC, Grzegorz Wierzowiecki
no flags Details
dmesg when Option "AccelDFS" "off" (42.37 KB, text/plain)
2010-07-08 13:41 UTC, Grzegorz Wierzowiecki
no flags Details

Description Grzegorz Wierzowiecki 2010-07-08 03:15:01 UTC
I've met many problems with scrolling and window moving, but not only.
In some apps, like OO-calc I meet wrongly rendered table... like part of screen copied and pasted with some offset in x and y axes. (Moving cursor refreshes those fragments, minimising and maximising window also might help... but enforcing refreshment is - at least - not comfortable).

In my case - ATI HD4350 PCI-E - problem appears when using DualHead mode,
with turned off KDE Composition (OpenGL) in order to use basic rendering techniques (when using Composition, OpenGL etc. KDE crashes and X-Server restarts... but when playing OpenGL games like TuxRacer everything is ok).

My setup is to 1900x1200 monitors in Dual Head, one is in pivot.
When using single head setup it is ok.

What I've found, is that 
Putting option:

Option      "AccelDFS" "off"

into xorg.conf, helped (even I have PCI-E card), not rendering is correct, but performance decreased dramatically.

My software version is

$ LC_ALL=en pacman -Qi xorg-server | grep Version
Version        : 1.8.1.902-1

$ LC_ALL=en pacman -Qi xf86-video-ati | grep Version
Version        : 6.13.0-1

How could I help you to fix this?
(btw. Is it right place to file such bug, or is there better?)
Comment 1 Michel Dänzer 2010-07-08 09:06:56 UTC
(In reply to comment #1)
> My setup is to 1900x1200 monitors in Dual Head, one is in pivot.
> When using single head setup it is ok.

How about dual head but without rotation? (Does the corruption only appear on the rotated or only on the non-rotated head, or on both?)
Comment 2 Grzegorz Wierzowiecki 2010-07-08 11:45:32 UTC
Created attachment 36856 [details]
Screenshot: Dolphin as should be.png
Comment 3 Grzegorz Wierzowiecki 2010-07-08 11:46:27 UTC
Created attachment 36857 [details]
Screenshot: Dolphin after moving around from one to another desktop.png
Comment 4 Grzegorz Wierzowiecki 2010-07-08 11:47:29 UTC
Comment on attachment 36857 [details]
Screenshot: Dolphin after moving around from one to another desktop.png

I blurred private data in upper-right corner.
Comment 5 Grzegorz Wierzowiecki 2010-07-08 11:50:35 UTC
I've made tests.

When there is DualHead without Pivot ("normal" = no rotation) it is all ok.

When there is DualHead with one or two Pivot screens (I've tested rotation left) then it is messed up with AllowDFS=on, tearing.

With allowdfs no tearing but performance dramatically falls down :/.
Comment 6 Grzegorz Wierzowiecki 2010-07-08 11:51:44 UTC
(In reply to comment #5)
> I've made tests.
> 
> When there is DualHead without Pivot ("normal" = no rotation) it is all ok.
> 
> When there is DualHead with one or two Pivot screens (I've tested rotation
> left) then it is messed up with AllowDFS=on, tearing.
> 
> With allowdfs no tearing but performance dramatically falls down :/.

I meant "With allowdfs=off", there is no tearing, but performance dramatically falls down :/.
Comment 7 Alex Deucher 2010-07-08 11:56:48 UTC
Please attach your xorg log and dmesg output.
Comment 8 Grzegorz Wierzowiecki 2010-07-08 13:31:00 UTC
Created attachment 36884 [details]
Xorg log with "Option "AccelDFS" "off" " , what means to me : properly with very slow performance
Comment 9 Grzegorz Wierzowiecki 2010-07-08 13:41:10 UTC
Created attachment 36885 [details]
dmesg when Option "AccelDFS" "off"

Don't know what to grep, so I put whole dmesg. If someone like grepped version, please let me know what lines to "grep", and I'll make it. Best - greg.
Comment 10 Grzegorz Wierzowiecki 2010-07-08 13:42:48 UTC
Comment on attachment 36885 [details]
dmesg when Option "AccelDFS" "off"

-----
Don't know what to grep, so I put whole dmesg. If someone like grepped version,
please let me know what lines to "grep", and I'll make it. Best - greg.
Comment 11 Michel Dänzer 2010-07-09 07:35:30 UTC
(In reply to comment #5)
> When there is DualHead without Pivot ("normal" = no rotation) it is all ok.
> 
> When there is DualHead with one or two Pivot screens (I've tested rotation
> left) then it is messed up with AllowDFS=on, tearing.

So, does the corruption only appear on the rotated outputs, or also on non-rotated ones?
Comment 12 Grzegorz Wierzowiecki 2010-07-09 10:28:12 UTC
> So, does the corruption only appear on the rotated outputs, or also on
> non-rotated ones?

Both screens behaves in same way (to me).


One more detail:
(I don't know if it's  important in this issue)

First -left- column of pixels of right (rotated) screen
is copy of last-right- column of pixels of my left screen.

At my setup, rotated screen is on right side and it's primary.
Setup is made on KDE startup with following autorun script : 

xrandr --output HDMI-0 --off --output VGA-0 --mode 1920x1200 --pos 1920x0 --rotate left --output DVI-0 --mode 1920x1200 --pos 0x332 --rotate normal

This detail is not problem to me, case always I can make a little bit bigger offset of right screen with xrandr.

I mention this cause it looks strange to me... and maybe somehow connected with tearing of screen (when Option "AccelDFS" "on"), cause teating is like rendering/refreshing some parts sometimes with wrong X,Y offset.

Why this column overlapping seems strange to me ?
When width of first screen is 1920, I assume it's Y axes range is [0;1919], so offset 1920 of second screen (=> range [1920,3119]) should not overlap, but it overlaps.
Comment 13 Alex Deucher 2010-07-09 11:13:54 UTC
(In reply to comment #12)
> Why this column overlapping seems strange to me ?
> When width of first screen is 1920, I assume it's Y axes range is [0;1919], so
> offset 1920 of second screen (=> range [1920,3119]) should not overlap, but it
> overlaps.

the overlap was an xserver bug that was fixed in this commit:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=80d1a548d6ce73c2ff097536c1bc7044bf74965d
Comment 14 Grzegorz Wierzowiecki 2010-07-09 11:42:10 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > Why this column overlapping seems strange to me ?
> > When width of first screen is 1920, I assume it's Y axes range is [0;1919], so
> > offset 1920 of second screen (=> range [1920,3119]) should not overlap, but it
> > overlaps.
> 
> the overlap was an xserver bug that was fixed in this commit:
> http://cgit.freedesktop.org/xorg/xserver/commit/?id=80d1a548d6ce73c2ff097536c1bc7044bf74965d


Thank you for info and commit's diff url.

So this detail is not related.

So we have to look with this tearing somewhere else.
Could I help you by running some programs in verbose mode, etc. ?
Comment 15 Grzegorz Wierzowiecki 2010-07-10 04:54:12 UTC
(In reply to comment #0)
> I've met many problems with scrolling and window moving, but not only.
> In some apps, like OO-calc I meet wrongly rendered table... like part of screen
> copied and pasted with some offset in x and y axes. (Moving cursor refreshes
> those fragments, minimising and maximising window also might help... but
> enforcing refreshment is - at least - not comfortable).
> 
> In my case - ATI HD4350 PCI-E - problem appears when using DualHead mode,
> with turned off KDE Composition (OpenGL) in order to use basic rendering
> techniques (when using Composition, OpenGL etc. KDE crashes and X-Server
> restarts... but when playing OpenGL games like TuxRacer everything is ok).
> 
> My setup is to 1900x1200 monitors in Dual Head, one is in pivot.
> When using single head setup it is ok.
> 
> What I've found, is that 
> Putting option:
> 
> Option      "AccelDFS" "off"
> 
> into xorg.conf, helped (even I have PCI-E card), not rendering is correct, but
> performance decreased dramatically.
> 
> My software version is
> 
> $ LC_ALL=en pacman -Qi xorg-server | grep Version
> Version        : 1.8.1.902-1
> 
> $ LC_ALL=en pacman -Qi xf86-video-ati | grep Version
> Version        : 6.13.0-1
> 
> How could I help you to fix this?
> (btw. Is it right place to file such bug, or is there better?)

Let me go into a few details, what do I mean by "performance decreased"/"slow performance", I hope it might help.

Slow performance with <<Option "AccellDFS" "off">> in xorg.conf, but with proper rendering.

Slow performance means, everything "freezes", making like 1fps or maybe even 0.5fps (1 frame per 1-3 seconds) when :
* moving window
* scrolling contents of windows (no metter kde,gnome - WM is KDE)
* using some apps like:
** typing in OpenOffice
** typing in firefox
** etc.

While, some features perform well, like:
* watching video
* 3d opengl stuff
* virtual machine in virtualbox
* most console apps (most of my work)

But when one of those runs in parrarell with one of those from first group, like for example:
* watching video and typing/scrooling/window-moving in OO/firefox
Than everything "freezes" and goes into "1 frame per 1-3 seconds".

Connection is that, those activities, which involves "freezing mode"/"1 frame per 1-3 second" seems like similar or even the same, which makes "tearing" or problems with refeshing in normal performance mode <<Option "AccellDFS" "on">>.

Best Greg.
Comment 16 Michel Dänzer 2010-07-12 02:38:42 UTC
(In reply to comment #12)
> > So, does the corruption only appear on the rotated outputs, or also on
> > non-rotated ones?
> 
> Both screens behaves in same way (to me).

So it sounds like maybe some hardware state leaks from the rotated blit operations into the DownloadFromScreen operations.
Comment 17 Alex Deucher 2012-04-25 06:02:28 UTC
Is this still an issue with a newer driver/kernel?
Comment 18 Grzegorz Wierzowiecki 2012-06-21 12:55:26 UTC
Unfortunately I can't perform checks now.

I'll try to make appropriate tests in next two months.
Comment 19 Martin Peres 2019-11-19 07:29:54 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/9.


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.