|Summary:||[Bisected]. [Regression]. Wayland. Chromium. Opening on full-screen mode videos lead to flickering white/black squads|
|Component:||Drivers/DRI/i965||Assignee:||Intel 3D Bugs Mailing List <intel-3d-bugs>|
|Status:||RESOLVED MOVED||QA Contact:||Intel 3D Bugs Mailing List <intel-3d-bugs>|
|i915 platform:||i915 features:|
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 <firstname.lastname@example.org> 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.