Bug 111618

Summary: [Bisected]. [Regression]. Wayland. Chromium. Opening on full-screen mode videos lead to flickering white/black squads
Product: Mesa Reporter: Denis <denys.kostin>
Component: Drivers/DRI/i965Assignee: Intel 3D Bugs Mailing List <intel-3d-bugs>
Status: RESOLVED MOVED QA Contact: Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity: not set    
Priority: not set    
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: video_with_bug

Description Denis 2019-09-09 14:09:32 UTC 
Created attachment 145309 [details]
video_with_bug

Hello. During using Chromium on wayland I faced with an issue - huge white/black squads flickering over the screen, in case if I opened video into full-screen mode.

OS: Manjaro
Linux den-pc 5.2.11-1-MANJARO
Xorg-server 1.20.5-2 (Xwayland and all related packs the same version)
Chromium (chromium)  76.0.3809.132-1 (tested and on downgraded version)
Mesa versions - git-master, 19.1.5 (system) etc...

Steps:
1. Login into wayland session
2. Launch chromium
3. Open chromium into full-screen mode (it is important, because in other way bug can't be reproduced)
4. Launch any youtube video
5. Open video in a full-screen mode
Result: picture starts flickering with white-black squads. Video attached.

I searched for same/similar issues and could find only these, quite old and resolved mostly:
https://bugs.freedesktop.org/show_bug.cgi?id=106841
https://bugs.chromium.org/p/chromium/issues/detail?id=849682
https://bugs.freedesktop.org/show_bug.cgi?id=111140

Second thing - is that running with "--disable-gpu-driver-bug-workarounds" - resolves issue.

Bisection lead me to:

069fdd5f9facbd72fb6a289696c7b74e3237e70f is the first bad commit
commit 069fdd5f9facbd72fb6a289696c7b74e3237e70f
Author: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Date:   Fri Jul 7 02:54:26 2017 -0400

    egl/x11: Support DRI3 v1.1

Issue doesn't exist on Xorg session. Possibly (as in found tickets) it may be related to regression in Xwayland, but I am not sure in this.
Comment 1 Lionel Landwerlin 2019-09-09 14:19:49 UTC 
That is usually a desynchronization between the compositor and the client (chromium) of state of the compression of the surface.

One is rendering compressed, the other reading uncompressed. We recently pointed mutter/gnome-shell to avoid reading the texture of a shared surface from the CPU (glReadPixels, etc...) because it would trigger that.

We should probably fix the driver, but this is somewhat of a rewrite of how we deal with aux surfaces.
Comment 2 GitLab Migration User 2019-09-25 20:35:37 UTC 
-- 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/mesa/mesa/issues/1833.

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.