Created attachment 129091 [details] dmesg output Hello graphics team, I am on an almost up-to-date (kernel at 4.9.4 ATM) Arch Linux system with the [testing] repository enabled. My hardware is the old integrated GPU in an AMD E2-2000 mobile CPU (Wrestler [Radeon HD 7340]) using the Radeon r600 driver. A few weeks ago before Christmas, I noticed that a stable tear appeared in movie players and games using OpenGL on X11. This was most likely caused by a package update but I did not investigate further. In hindsight, the reason was most likely the package update from xf86-video-ati 7.8.0-2 -> 7.8.99.r13.g404c6475 that I performed on 2016-12-16 (There appeared an Arch bug report implicating this version [1]. The package is currently at 7.8.99.r16.gea30d856 but the problem still exists. As far as I can see, nobody else reported this upstream, yet.). I have a 1366x768 display and the tear seems to appear be at a height of ~100 pixels from the top. Also, it seems to start at 0x0 (from top left) with a short diagonal to about 100x100 and then reaches horizontally all the way to the right. This tear does not appear under Wayland, for me. It also seems to disappear as soon as DRI3 is disabled by setting the xorg.conf option or by setting LIBGL_DRI3_DISABLE=1 before starting, e.g. the video player or the game (video player: mpv --vo=opengl --hwdec=vdpau, game: Stardew Valley). As far as I remember, I had DRI3 explicitly enabled in my xorg.conf without any problems before this package update. I tried capturing the issue with my cell phone camera but was unsuccessful. Reading the mailing list, I noticed a few recent bug reports due to DRI3 but I did not find one complaining about tearing. Similar reports appear to be quite a bit older. I might have missed something, though or somebody else participating in [1] might have reported it in the meantime. The versions of the packages that might be relevant are: xf86-video-ati 7.8.99.r16.gea30d856 linux 4.9.4 xorg-server 1.19.1 mesa 13.0.3 llvm 3.9.1 The Xorg.0.log, glxinfo output and kernel log should be attached. Thank you for your work on the graphics stack. --- [1] https://bugs.archlinux.org/task/52620
Created attachment 129092 [details] Xorg log
Created attachment 129093 [details] glxinfo output
Created attachment 129123 [details] [review] Enable tiling by default with glamor on PALM Does this patch fix the problem?
(In reply to Michel Dänzer from comment #3) > Created attachment 129123 [details] [review] [review] > Enable tiling by default with glamor on PALM > > Does this patch fix the problem? Hi, your patch does, indeed, seem to fix my tearing issues. I tested both mpv and Stardew Valley with a patched xf86-video-ati package and the horizontal artifact was gone with DRI3 enabled. Is this fix only for PALM chips? The other bug reporters on the Arch tracker did not post their setups, unfortunately, but I doubt they are all using similar GPUs. In any case, thank you very much.
(In reply to andreaskem from comment #4) > Is this fix only for PALM chips? The other bug reporters on the Arch tracker > did not post their setups, unfortunately, but I doubt they are all using > similar GPUs. Yes, this issues is PALM specific. Users with other GPUs can't have the same problem and would need to file their own bug reports. > In any case, thank you very much. Thank you for the report and testing. Please only resolve bug reports once the fix has landed in Git. Which is the case now: commit d611d21d9bf9aaa100ff7a5762e5980634846207 Author: Michel Dänzer <michel.daenzer@amd.com> Date: Tue Jan 24 18:05:45 2017 +0900 Enable tiling by default with glamor on PALM
Hello, despite this "palm patch" I still have the bug, my graphic card is "amd radeon HD4650 Pcie" ( chip: RV730 pro ), I use archlinux 64 bits
(In reply to Barto from comment #6) > despite this "palm patch" I still have the bug, > > my graphic card is "amd radeon HD4650 Pcie" ( chip: RV730 pro ), Please file your own report.
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.