Like described on the amdvlk bugtracker, there is a slight amount of tearing very close to the top of the screen, despite of the application's vsync being enabled: https://github.com/GPUOpen-Drivers/AMDVLK/issues/16#issuecomment-369588472 This happens with latest xorg-server 1.19.6, with both xf86-video-amdgpu and modesetting, mesa 17.3.6 and latest amdvlk-git. The tearing may not be overly easy to spot and of course xorg compositors with vsync should be disabled. Using compositors with vsync or the TearFree option help as workarounds, but aren't optimal. Vsync in OpenGL applications works fine with RadeonSI on the same system without workarounds. Like stated on the amdvlk GitHub tracker, AMD developer davidmaoamd assumes there there is a connection with using copy for present, which would explain why radv is only affected in windowed mode and amdvlk in both windowed and fullscreen.
(In reply to tempel.julian from comment #0) > Using compositors with vsync or the TearFree option help as workarounds, but > aren't optimal. > Vsync in OpenGL applications works fine with RadeonSI on the same system > without workarounds. > > Like stated on the amdvlk GitHub tracker, AMD developer davidmaoamd assumes > there there is a connection with using copy for present, which would explain > why radv is only affected in windowed mode and amdvlk in both windowed and > fullscreen. Assuming radeonsi is also affected in windowed, this is indeed how things are with Xorg. The only ways to reliably avoid tearing are: * If the application runs fullscreen and can use page flipping * If a compositing manager is used, which can use page flipping * By enabling TearFree
RadeonSI does work correctly with vsync, there is no tearing in any window (be it a game or application). Only Vulkan drivers are affected. And amdvlk is also affected in fullscreen.
(In reply to tempel.julian from comment #2) > RadeonSI does work correctly with vsync, there is no tearing in any window That's only possible with a compositor which can prevent tearing, or simply due to luck (e.g. because the window doesn't cover the range of the monitor affected by tearing). > And amdvlk is also affected in fullscreen. That's because AMDVLK explicitly prevents page flipping. The only solution there is compositing (make sure the compositing manager doesn't unredirect the AMDVLK fullscreen windows) or TearFree.
Thanks for still responding, despite of the closed ticket. I can assure you that with OpenGL/RadeonSI in an Xorg session, application's own vsync really does work correctly without the help of a compositor, even in windowed mode. Let's take Firefox as an example: With "layers.acceleration.force-enabled" in about:config, you can enable OpenGL rendering of Firefox. With this, e.g. scrolling or the website www.vsynctester.com is _absolutely_ free of tearing, it's perfectly synchronized to the display's refreshrate. I checked this with several desktop environments which allow to disable their Xorg compositor, such as KDE Plasma or XFCE. It definitely does work without the help of a compositor. Would it be an option to suggest that amdvlk/radv explicitly make use of page flipping instead? Because using the compositor to deal with vsync is quite unfortunate, it costs a bit of performance and adds additional input latency by having an own additional frame buffer queue. Furthermore, the only compositor which can be configured in detail regarding unredirecting single applications would be Compton. E.g. Gnome Mutter does always unredirect in fullscreen, so there would be no way of getting proper vsync in fullscreen in a Gnome Xorg session.
(In reply to tempel.julian from comment #4) I'm sorry, but you're just getting lucky with radeonsi. With Firefox, maybe the tearing could only occur in the title bar / toolbar area. If you can't find a satisfactory compositor setup, try TearFree. Those are your options for avoiding tearing with any reliability. > Would it be an option to suggest that amdvlk/radv explicitly make use of > page flipping instead? They can't do that. They can only not explicitly prevent page flipping, but radv already doesn't do that AFAIK. It can only make a difference in fullscreen anyway. Another possible reason that Vulkan might work less well is if the Vulkan drivers use MSC targets which have already passed, and/or use the PresentOptionAsync flag for PresentPixmap requests. That would have to be addressed in the Vulkan drivers or possibly the applications themselves; the Xorg driver is just doing what it's asked.
You are right, I've hidden the titlebar of Firefox' window and moved it to the top of the screen where I could spot tearing in windowed mode without compositor. I just hope situation can be mitigated in some way for fullscreen with amdvlk without TearFree/compositor. Else one would need some ugly workaround like starting another Xorg session without TearFree if the goal is to play a game without vsync or something like that. :( Thanks for your help, really appreciate it!
(In reply to tempel.julian from comment #6) > Else one would need some ugly workaround like starting another Xorg session > without TearFree if the goal is to play a game without vsync or something > like that. :( With current xf86-video-amdgpu, TearFree can be toggled at runtime: xrandr --output <output name> --set TearFree on [/ off / auto] See the amdgpu manpage for more information.
Well, I guess it's acceptable for an enthusiast who wants to play without vsync to press a hotkey before starting a game to change TearFree behavior. :)
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.