Created attachment 137094 [details] misrendered pixels at top of page Recently I have notice some rendering artifacts when running Firefox on Mesa 18.0rc3. It shows up as a rectangular block of misrendered pixels, in a checkerboard pattern. It is hard to catch, but I managed to record my desktop with the rendering. See attached. I'm running: - Linux 4.14.0-3 - ̂ͧ̌̿ͣͥM̓̌ͫ͗e̒̃̈́̈́ͫs̅̏a ̄̇ͯ͑18.0͂rͩ͌ͧc͆͌̈́ͣͮ̂3͒̆ - KBL GT2 - F̌̏̑i͐ͤ̔ͪȓ͆̍̃̔eͮ͒͆ͩf̔̍̔͂͑oͤ͗ͪx̄͑͒̂̂̃ 52.5 If anyone has seen something similar, Please help. by finding a reproducible case that we can use to bisect. I usually see it on our Jenkins page hopefully the Nezperdian hive-mind of c͗ͥͩh̑͋ͪaos̃̊̐̋ is not in the lab. My shader crache is enabled but He who Waits Behind The Wall will not permit. ͗͑̊i͑ͮ͛ͬsͤ̉̌̎̒ ͧt̾͊h̅̋̀ͪa̓̂͂͌t̾ blood? ͥ̚ZĂ̋̐͒Lͦ̔ͭGͭO!ͥͥͧ̊
I too experience this issue on Kabylake GT2. However, I'm uncertain of why you decided to call us. Everyone knows the correct people to call are the Ghostbusters. Thanks for the report!
Reproduces on firefox 58 and firefox 52.
I see this corruption with Mesa 17.3 but not 17.2.
Jason asked me to check d6d0ac95d5d77bd18b2064c3ed9aad70cf38cb6f, the last good commit before copy-image tests failed. I could see the distortion at that commit.
This corruption seems easier to reproduce using a google docs spreadsheet. As you mouse over elements, the artifacts appear.
This is likely to be related to firefox's layers.acceleration.force-enabled setting. Both Ken and myself had gpu rendering enabled, which is not the default setting.
Are you able to reproduce this with INTEL_DEBUG=norbc? I haven't been able to reproduce this after trying for several days on the following system config: * HSW (doesn't have CCS_E) * mesa-git * layers.acceleration.force-enabled = true
I have not been able to reproduce this with norbc.
Lionel found this user experiencing the same thing: https://twitter.com/ebassi/status/966614066881073152
Hi, I'm a Firefox 58 user on Intel Kabylake (Dell XPS 9360) tweeting rendering bugs, AMA. - Fedora 27 - Linux 4.15.3-300.fc27.x86_64 - Firefox 58.0.2, with layers.acceleration.force-enabled set to true - Mesa 17.3.4
Created attachment 137564 [details] [review] disable blorp texture upload Jason Ekstrand looked at a the way Firefox renders a problematic page in FrameRetrace. He suggested disabling blorp texture upload. I have been running with this patch today, and have not seen any artifacts.
Able to reproduce it several times but there is no reliable test procedure for this. I recorded apitrace with this bug but on replay it is gone. My setup info: OS: Ubuntu 16.04 LTS 64 bit Firefox: 58.0.2 (64-bit) Mesa: 18.1.0-devel (git-33633690aa) CPU: Intel® Core™ i7-8550U CPU @ 1.80GHz × 8 GPU: Intel® UHD Graphics 620 (Kabylake GT2)
*** Bug 105332 has been marked as a duplicate of this bug. ***
I'm using Firefox as a main browser and didn't see any artifacts until enabling "layers.acceleration.force-enabled" setting. With this option enabled, I'm seeing rare artifacts when switching mail filters in gmail (but they are mostly black, not pink). Firefox 52.6.0 (64-bit) and Mesa 17.3.3 from Debian testing. I think this confirms Comment 6.
Good news everyone! I think I figured out how to reliably reproduce zalgo! In particular, if you make a new firefox window that's relatively small and then maximize and unmaximize it, you can get zalgo during the resize. This may or may not be the same zalgo but it definitely looks like CCS corruption.
Removing from Mesa 18.0 blockers list as discussed on IRC and elsewhere.
Jason, unfortunately this method doesn't work for me. I'm experiencing random corruptions, mostly on pages itself, independent of their complexity. Corruptions are rare, but come in packs (like for several seconds) so in my case they looks related to some background process and not the page itself.
Reverting following commit fixes zalgo issue for me: commit 157faa407f51829fb8b2d2af723547dc8a0d3849 Author: Jason Ekstrand <jason.ekstrand@intel.com> Date: Wed May 31 17:53:34 2017 -0700 i965/tex: Use blorp texture upload for all CCS_E textures This improves the FillTex benchmark in GLBench 2.7 by 30% on my Broxton. On Ken's Broxton which only has single-channel ram, it improves by 210%. v2 (Ken): Check mt->aux_usage == ISL_AUX_USAGE_CCS_E rather than using intel_miptree_is_lossless_compressed(). Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Can anyone else check it please ? Also I tried a patch in 105351 Bug https://bugs.freedesktop.org/attachment.cgi?id=138163. Issue looks quite similar, but that patch didn't help.
Vadym, based on resolution of a similar bug, this may be a bug in firefox. I was unable to see Zalgo with this patch from bug 105332: https://bugs.freedesktop.org/attachment.cgi?id=138120 Can you try that patch and confirm that it fixes firefox as well? I've not seen corruption but as we all know it is hard to reproduce.
Tested: - Reverting commit 157faa407f51829fb8b2d2af723547dc8a0d3849 - patch from bug 105332: https://bugs.freedesktop.org/attachment.cgi?id=138120 And both methods are solving the issue for me.
I'm resolving this as NOTOURBUG. Apparently this is/was a Firefox issue using same texture with multiple GL contexts and not handling synchronization properly.
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.