Summary: | Screen tearing (some tiles rendered with offset) especially when scrolling etc. in DualHead mode on HD4350 | ||
---|---|---|---|
Product: | xorg | Reporter: | Grzegorz Wierzowiecki <gwpublic> |
Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> |
Status: | RESOLVED MOVED | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | normal | ||
Priority: | medium | CC: | hramrach |
Version: | unspecified | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Description
Grzegorz Wierzowiecki
2010-07-08 03:15:01 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?) Created attachment 36856 [details]
Screenshot: Dolphin as should be.png
Created attachment 36857 [details]
Screenshot: Dolphin after moving around from one to another desktop.png
Comment on attachment 36857 [details]
Screenshot: Dolphin after moving around from one to another desktop.png
I blurred private data in upper-right corner.
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 :/. (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 :/. Please attach your xorg log and dmesg output. Created attachment 36884 [details]
Xorg log with "Option "AccelDFS" "off" " , what means to me : properly with very slow performance
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 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.
(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? > 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.
(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 (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. ? (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. (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. Is this still an issue with a newer driver/kernel? Unfortunately I can't perform checks now. I'll try to make appropriate tests in next two months. -- 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.