Created attachment 137763 [details] Graphic corruption on the page with hyperlink Android app Amazon Kindle reader shows empty pages in reading mode when page contain images or hyper links. Issue is reproducible on Android IA and narrowed to 17.2 - 17.3 rev bump in Android IA / Chrome OS ARC++ It can be reproduced with sample of the book "The Death of Expertise" that contain pages with pictures and links.
Please bisect mesa to find the patch that causes this misrendering.
Issue can be fixed with patch from https://bugs.freedesktop.org/show_bug.cgi?id=104890
*** This bug has been marked as a duplicate of bug 104890 ***
I'm able to reproduce the empty pages on Android-IA but patch from bug #104890 causes problems in the Android UI.
Here is how I experience this bug: https://www.youtube.com/watch?v=jb22Dv_hb4o Page looks just completely awful without any glyphs rendered properly. Note that there is also lots of tearing during updates (which I haven't seen with other apps). Maybe this app is doing something special to trigger this. This was with Android-IA patches on top of old Mesa commit 8696c3e997.
Dmytro, your initial information seems to be incorrect. Tapani has reproduced this on 8696c3e997, which is before Mesa 17.2 When you investigated this bug, did you update only Mesa, or did you update other parts of Android/ChromeOS/ARC++ ? Please verify the information reported by Tapani.
With ChromeOS ARC I can reproduce issue with MESA 17.3-rc5 but issue gone after updating only MESA to 17.2-pre1 (same Chrome/ARC builds)
(In reply to Dmytro Chystiakov from comment #7) > With ChromeOS ARC I can reproduce issue with MESA 17.3-rc5 but issue gone > after updating only MESA to 17.2-pre1 (same Chrome/ARC builds) Can you also include which HW is used? I'm running Android-IA on Kabylake. I built a custom tree using 17.2-pre1 as a base from here: https://chromium.googlesource.com/chromiumos/third_party/mesa/+/arc-17.2.0-pre1 I can still reproduce this, my custom tree is available here: https://github.com/tpalli/external-mesa/tree/cros_17.2pre_on_AIA (Note that this tree does not build Vulkan properly and with current AIA you will need to disable Vulkan from mixins.spec and run mixin-update before building!)
Just some observations .. I noticed that when a page with a link or image is displayed, app shows the previous page that was shown without links or images instead. This 'last successful page' sometimes renders correctly but sometimes can be empty or corrupted version of it.
It works with this (the same) MESA branch on Pixelbook (KBL) with ChromeOS R65 BETA... https://chromium.googlesource.com/chromiumos/third_party/mesa/+/arc-17.2.0-pre1
(In reply to Dmytro Chystiakov from comment #10) > It works with this (the same) MESA branch on Pixelbook (KBL) with ChromeOS > R65 BETA... > https://chromium.googlesource.com/chromiumos/third_party/mesa/+/arc-17.2.0- > pre1 Yeah, I think we have other differences in the stack causing different behaviour. One thing is that on Android we do support CCS_E and that is why I cannot use patch from bug #104890 succesfully (since it breaks uploads for surfaces that have (mt->aux_usage == ISL_AUX_USAGE_CCS_E) set. I will try to disable CCS_E and see what I come up with.
> Yeah, I think we have other differences in the stack causing different > behaviour. One thing is that on Android we do support CCS_E and that is why I > cannot use patch from bug #104890 succesfully (since it breaks uploads for > surfaces that have (mt->aux_usage == ISL_AUX_USAGE_CCS_E) set. I will try to > disable CCS_E and see what I come up with. Any update?
(In reply to Dmytro Chystiakov from comment #12) > > Yeah, I think we have other differences in the stack causing different > > behaviour. One thing is that on Android we do support CCS_E and that is why I > > cannot use patch from bug #104890 succesfully (since it breaks uploads for > > surfaces that have (mt->aux_usage == ISL_AUX_USAGE_CCS_E) set. I will try to > > disable CCS_E and see what I come up with. > > Any update? Sorry no progress with this one, debugging this is quite difficult since there are severe regressions in current Android-IA stack, as example using Kindle app now causes hwcomposer to crash.
I've debugged further and it seems this bug is about ISL_AUX_USAGE_CCS_E. I can make these artifacts disappear when disabling CCS_E from miptree creation. One quick workaround would be to disable CCS_E on Android. I'm attaching here a patch I used to make this work.
Created attachment 138069 [details] [review] hack This makes us skip CCS_E in miptree creation.
During the usecase there are brw_blorp_copy_miptrees happening where src does not have CCS_E but dst has, format is MESA_FORMAT_R8G8B8A8_UNORM. I'm investigating if this has something todo with the corruption.
(In reply to Tapani Pälli from comment #16) > During the usecase there are brw_blorp_copy_miptrees happening where src > does not have CCS_E but dst has, format is MESA_FORMAT_R8G8B8A8_UNORM. I'm > investigating if this has something todo with the corruption. I think it probably is CCS-related corruption. The real question is why. I also saw some tearing when flipping between pages which may or may not be related. Unfortunately, I only got about 10 minutes to look at it today.
I've done some digging and it's 100% not a CCS issue. The only reason why CCS affects it is that we force-enable blorp texture upload for CCS images. Since the Kindle app doesn't use PBOs, blorp texture upload and CCS go hand in hand. If I force blorp texture upload but disable CCS, it still fails in the same way. We have some blorp texture upload bug. I also did an experiment where I tried to upload red instead of the image and that resulted in a bunch of stuff being red but ultimately the missing images were still white and not red. This leads me to believe that the texture upload just isn't happening for some reason.
I believe I've tracked down the problem and it's not mesa. The app is using two different contexts and I believe it is uploading the texture with glTexSubImage in one and using the texture in the second without properly synchronizing between them. Inserting a batchbuffer flush after a successful blorp texture upload works around the problem. I'm closing this as NOTOURBUG.
Created attachment 138120 [details] [review] Better (but still not good!) hack
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.