Bug 109235 - Using named pixmap of window right after resizing results in garbage content
Summary: Using named pixmap of window right after resizing results in garbage content
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/AMDgpu (show other bugs)
Version: git
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: 2019-01-06 21:00 UTC by Yuxuan Shui
Modified: 2019-01-22 20:51 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
The demonstration video of the problem. (8.11 MB, video/mp4)
2019-01-11 13:49 UTC, Arno Dupont
no flags Details

Description Yuxuan Shui 2019-01-06 21:00:31 UTC
compton is a glx based compositor, when a window is resized, compton release the previously bound pixmap, and create a new named pixmap and bind that to a texture, and then render the screen with that.

With the amdgpu/radeonsi driver, that sometimes result in garbage content.

You can find more details, screenshot, and recordings here [1]

[1]: https://github.com/yshui/compton/issues/85
Comment 1 Yuxuan Shui 2019-01-06 21:18:46 UTC
BTW, this problem doesn't happen with intel, or proprietary nvidia drivers.
Comment 3 Arno Dupont 2019-01-10 20:47:32 UTC
(In reply to Michel Dänzer from comment #2)
> Does
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/
> 21 fix it?

I am the one who initially created the problem on the Compton github and this merge request has solved my issue! 
Thank you very much for your very quick reaction!
Comment 4 tempel.julian 2019-01-11 10:42:57 UTC
I often had this issue when doing certain window operations while having high CPU load, e.g. when compiling on all available threads.
I tried several times to reproduce, but it seems the provided patch took care of it.
Comment 5 Arno Dupont 2019-01-11 13:45:49 UTC
I would like to point out that I have the problem that appears again but this time when a window is opened (this problem only appears for 1/10 of a second, and is especially visible with a transparent terminal).
Comment 6 Arno Dupont 2019-01-11 13:49:54 UTC
Created attachment 143070 [details]
The demonstration video of the problem.
Comment 7 Michel Dänzer 2019-01-11 14:02:51 UTC
(In reply to Arno Dupont from comment #6)
> The demonstration video of the problem.

Which window manager and compositing manager are you using? See e.g. https://github.com/i3/i3/issues/3577 for an i3 bug which causes similar symptoms.

Even if it's not a window manager / toolkit / application issue, it's probably not exactly the same cause anymore, so it's better if you file your own report.


P.S. some general remarks:

A bug report should only be resolved once the fix has landed in Git master.

A bug report should generally only be resolved or reopened by the submitter or a developer.
Comment 8 Arno Dupont 2019-01-11 15:09:24 UTC
Okay! I will check if the problem does not come from my configuration and create a new bug report if it persists. 

Thank you for your work.
Comment 9 Michel Dänzer 2019-01-11 17:17:18 UTC
Thanks for testing https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/21 . I added an optimization on top of the fixes, please re-test to make sure that doesn't re-introduce the problem.
Comment 10 Arno Dupont 2019-01-11 18:36:49 UTC
I have tried the new commits and the problem of garbage does not occur. 
Nevertheless, during my tests, I wanted to check (by coincidence) if the resizing performance had improved or not. That's where a crash happened. After ~one minute of intensive window resizing, my PC starts to lag and after some more resize freezes completely. I managed to reproduce it with your new commits with the one who initially solved the garbage problem. I also tried with the git master version and this crash is not there.

Best regards.
Comment 11 tempel.julian 2019-01-12 17:04:17 UTC
Haven't had any crashes (or other issues) with the old patch so far, trying the new one now.

I also experienced this kind of visual corruption not just inside Xorg sessions with Compton GLX compositing, but also with xwayland windows inside a KDE Plasma Wayland session. Just like Arno described, usually when starting applications, e.g. Firefox. It was way worse than with a native Xorg session.
Comment 12 Michel Dänzer 2019-01-14 11:20:11 UTC
(In reply to Arno Dupont from comment #10)
> After ~one minute of intensive window resizing, my PC starts to lag and
> after some more resize freezes completely. I managed to reproduce it with
> your new commits with the one who initially solved the garbage problem.

Not sure how to parse the latter sentence, but I assume you mean this new problem only occurs with the last commit adding the optimization. Otherwise please clarify.


(In reply to tempel.julian from comment #11)
> I also experienced this kind of visual corruption not just inside Xorg
> sessions with Compton GLX compositing, but also with xwayland windows inside
> a KDE Plasma Wayland session.

That can't possibly be the same issue, so it would need to be tracked separately. If it also happens with GNOME on Wayland, I'd file an issue against Xwayland, otherwise against kwin.
Comment 13 Arno Dupont 2019-01-14 13:08:30 UTC
(In reply to Michel Dänzer from comment #12)
> Not sure how to parse the latter sentence, but I assume you mean this new
> problem only occurs with the last commit adding the optimization. Otherwise
> please clarify.


I meant that this crash occurs with the first commit (47ae9034) and the last ones (with or without optimizations).
Comment 14 tempel.julian 2019-01-14 16:23:06 UTC
I can also provoke the Xorg to become laggy after some time of intensively resizing the Firefox window (OGL enabled via about:config), I managed to do this two times in a row with the PR patched into xf86-video-amdgpu-git. Without the PR, it didn't crash so far.
Comment 15 tempel.julian 2019-01-14 16:25:09 UTC
Edit: Sorry, I should have rechecked after reformatting my reply. It didn't crash so far, but I needed to restart to restore proper Xorg performance after intensive resizing.
Comment 16 Michel Dänzer 2019-01-15 11:13:04 UTC
Ah yes, the first patch was leaking GBM BOs. https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/21 updated again, please re-test.
Comment 17 Arno Dupont 2019-01-15 12:29:13 UTC
That sounds good! I didn't manage to reproduce the crash with these last commits.
Comment 18 tempel.julian 2019-01-15 14:38:19 UTC
Me neither, looking good so far.

As a sidenote: I also just realized how easily I can trick myself by accidentally installing a package from Pamac cache instead of the freshly created build in the PKGBUILD dir, which Pamac apparently ignored because the patch didn't affect the build number. My oh my, I suppose I almost reported something wrong because of this... :p
Comment 19 Michel Dänzer 2019-01-16 17:44:40 UTC
All merged, thanks for the report and testing!
Comment 20 tempel.julian 2019-01-22 20:51:43 UTC
While I haven't seen this corruption anymore when doing certain window operations, it occasionally very briefly still occurs when starting 3D applications (Xorg session). I suppose I can't provide more details, as it really seems to be totally random if it occurs, and too short to capture it somehow.


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.