Created attachment 133430 [details] dmeg Hello, I notice a bug since january 2017 : tearing in videos after the update of the package xf86-video-ati ( 1:7.8.99.r16.gea30d856-1 ), I use archlinux 64 bits, I tried the last package version : 1:7.9.0-1 and it's the same problem, If I downgrade the package to the version 1:7.8.0-2 then all is ok, my graphic card : amd radeon HD4650 Pcie ( chip: RV730 pro ), the original bug report in archlinux : https://bugs.archlinux.org/task/52620
Created attachment 133431 [details] glxinfo
Please attach the Xorg log file corresponding to the good and bad case. Most likely it's related to the default for Option "AccelMethod" switching from EXA to glamor for your GPU, but in that case you should have tearing with EXA as well, just less noticeable one (horizontal vs diagonal). To really eliminate tearing, you need to use a compositing manager that can reliably eliminate it.
Created attachment 133508 [details] xorg log file when xf86-video-ati 1.7.8 is used ( good case ) here is the xorg log file when the xf86-video-ati 1.7.8 is used ( good case, no bug, no tearing )
Created attachment 133509 [details] xorg log file when xf86-video-ati 1.7.9 is used ( bad case, tearing ) and here is the xorg log file when the 1.7.9.0 version of xf86-video-ati is used ( bad case, a lot of tearing in videos, and sometimes corrupt menus display )
precisions : I don't use a custom configuration file for radeon in /etc/X11/xorg.conf.d/ ( there is no radeon.conf file ) so the driver will use the default values, I use plasma 5 ( kde ), openGL 2.0 is activated in kde for the compositor, there is no problem with 1:7.8.0-2 version of xf86-video-ati ( and also the previous versions ), the bugs starts with the version 1:7.8.99, you have probably introduced something that triggers a lot of tearings in my graphic card radeon HD4650 ( RV730 pro ), I think this bug is easily reproducible, the use case is : - take an old radeon graphic card, for example radeon HD series 4xxx - don't use a custom radeon configuration file in /etc/X11/xorg.conf.d/ - use plasma 5 as compositor, with the default value ( openGL 2.0 ) - use a rolling release linux distro, like archlinux 64 bits, all the system package will be up to date with this use case you will notice the bug easily when running videos ( with VLC, mplayer ), a lot of tearing will be visible on scenes ( travelling scenes )
Which vsync setting are you using in the kwin compositing preferences? "Reuse screen contents" should work best with DRI3.
vsync setting is set to "never" in plasma 5 compositor, with 1:7.8 version I don't see tearing in videos even if the vsync is set to "never", but with 1:7.9 version I see tearing when vsync is set to never, if I chose ""Reuse screen contents" then I get a warning in the GUI compositor about the risk on instability of mesa driver, with this setting I notice that the background of my desktop "blinks" when VLC plays a video, the display is corrupted, with the setting "automatic" it's better, I see no tearing ( for the moment ) with 1:7.9, does it mean that the vsync is mandatory with 1:7.9 version ? it doesn't seem normal to have to activate the vsync setting in compositor, with the previous version of xf86-video-ati I never seen tearing in videos when the vsync setting was disabled in the compositor, for me tearing should be seen only on 3D video games when the framerate doesn't match with the framerate of the monitor
This is not a bug. Sync-to-vblank is the mechanism to avoid tearing. With it disabled, there can definitely be tearing even with EXA. You were just lucky to never hit/notice it.
P.S. If you don't want to use kwin's tearing avoidance functionality for some reason, you can use TearFree instead: xrandr --output DVI-0 --set TearFree on
Ok, I notice also that DRI 3 is enabled by default in 1:7.9.x : $ cat bad_case_xorg_log_video-ati-1.7.9.0.txt | grep DRI [ 12603.610] (II) glamor: EGL version 1.4 (DRI2): [ 12603.703] (II) RADEON(0): [DRI2] Setup complete [ 12603.703] (II) RADEON(0): [DRI2] DRI driver: r600 [ 12603.703] (II) RADEON(0): [DRI2] VDPAU driver: r600 [ 12603.704] (==) RADEON(0): DRI3 enabled [ 12603.823] (II) GLX: Initialized DRI2 GL provider for screen 0 but not in 1:7.8 : $ cat good_case_xorg_log_video-ati-1.7.8.0.txt | grep DRI [ 69.914] (II) RADEON(0): [DRI2] Setup complete [ 69.914] (II) RADEON(0): [DRI2] DRI driver: r600 [ 69.914] (II) RADEON(0): [DRI2] VDPAU driver: r600 [ 69.920] (==) RADEON(0): DRI3 disabled [ 72.787] (II) GLX: Initialized DRI2 GL provider for screen 0 I think it can explain why I see no tearing with "vsync disabled" in 1:7.8.x version, with DRI 2 it seems that there is no need to activate vsync, but with DRI 3 I have to activate vsync in order to avoid tearing
(In reply to Michel Dänzer from comment #9) > P.S. If you don't want to use kwin's tearing avoidance functionality for > some reason, you can use TearFree instead: > > xrandr --output DVI-0 --set TearFree on so the solution I found is to create a radeon.conf file in /etc/X11/xorg.conf : Section "Device" Identifier "Radeon" Driver "radeon" Option "TearFree" "on" Option "DRI" "3" Option "AccelMethod" "glamor" EndSection I have a suggestion : you should enable by default "TearFree on" if the graphic card supports both DRI 3 and glamor, it will permit to eliminate tearing even if vsync is set to "never" in kwin
in fact I notice that by default in 1:7.9.x Tearfree option is set on "auto" : $ cat bad_case_xorg_log_video-ati-1.7.9.0.txt | grep Tear [ 12603.614] (==) RADEON(0): TearFree property default: auto the auto mode doesn't work with my graphic card as I see tearing on videos, but if I explicitely set Tearfree to "ON" then the tearing disapears, maybe there is a bug in this "auto mode feature" for tearfree ?
It's not directly related to DRI3 vs DRI2. By setting vsync to "never" in kwin, you basically tell it that you don't mind tearing. The meaning of the "auto" value of the per-output TearFree property is documented in the radeon manpage.
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.