Bug 105332 - Empty or corrupted graphic on book pages when reading on Android app Amazon Kindle reader
Summary: Empty or corrupted graphic on book pages when reading on Android app Amazon K...
Status: RESOLVED NOTOURBUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 17.3
Hardware: x86 (IA32) other
: medium normal
Assignee: Dmytro Chystiakov
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-03 02:12 UTC by Dmytro Chystiakov
Modified: 2018-03-15 01:08 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Graphic corruption on the page with hyperlink (847.94 KB, image/png)
2018-03-03 02:12 UTC, Dmytro Chystiakov
Details
hack (865 bytes, patch)
2018-03-13 09:26 UTC, Tapani Pälli
Details | Splinter Review
Better (but still not good!) hack (930 bytes, patch)
2018-03-15 01:08 UTC, Jason Ekstrand
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Dmytro Chystiakov 2018-03-03 02:12:50 UTC
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.
Comment 1 Mark Janes 2018-03-05 14:31:33 UTC
Please bisect mesa to find the patch that causes this misrendering.
Comment 2 Dmytro Chystiakov 2018-03-05 22:56:13 UTC
Issue can be fixed with patch from https://bugs.freedesktop.org/show_bug.cgi?id=104890
Comment 3 Mark Janes 2018-03-06 00:41:32 UTC

*** This bug has been marked as a duplicate of bug 104890 ***
Comment 4 Tapani Pälli 2018-03-07 06:33:48 UTC
I'm able to reproduce the empty pages on Android-IA but patch from bug #104890 causes problems in the Android UI.
Comment 5 Tapani Pälli 2018-03-07 11:40:26 UTC
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.
Comment 6 Mark Janes 2018-03-07 17:29:25 UTC
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.
Comment 7 Dmytro Chystiakov 2018-03-08 00:04:46 UTC
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)
Comment 8 Tapani Pälli 2018-03-08 06:54:22 UTC
(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!)
Comment 9 Tapani Pälli 2018-03-08 09:09:46 UTC
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.
Comment 10 Dmytro Chystiakov 2018-03-08 21:20:08 UTC
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
Comment 11 Tapani Pälli 2018-03-09 06:34:35 UTC
(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.
Comment 12 Dmytro Chystiakov 2018-03-12 23:34:27 UTC
> 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?
Comment 13 Tapani Pälli 2018-03-13 06:44:59 UTC
(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.
Comment 14 Tapani Pälli 2018-03-13 09:25:26 UTC
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.
Comment 15 Tapani Pälli 2018-03-13 09:26:55 UTC
Created attachment 138069 [details] [review]
hack

This makes us skip CCS_E in miptree creation.
Comment 16 Tapani Pälli 2018-03-13 12:53:14 UTC
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.
Comment 17 Jason Ekstrand 2018-03-14 03:48:56 UTC
(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.
Comment 18 Jason Ekstrand 2018-03-15 00:08:01 UTC
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.
Comment 19 Jason Ekstrand 2018-03-15 01:01:14 UTC
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.
Comment 20 Jason Ekstrand 2018-03-15 01:08:30 UTC
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.