Chrome beta on Android still seems to have the issue. I have also viewed the webpage via the following app - com.eas.cordova.browser - which seems to display the page correctly but I am guessing it is using an older version of webkit that does not have this SVG rendering issue?

I can't reproduce this problem on a Nexus 5x with Chrome 54 or 55, nor on desktop linux Chrome 55 in device emulation mode. If I recall correctly, the meta viewport tag enabled GPU rendering, so the issue presumably has something to do with that (but I cannot figure out why).

What device are you working with? Can you please try Chrome Canary and see if the issue reproduces there?

Hi Schenney,

I'm using a Pixel XL phone running Android 7.1. The issue doesn't seem to be present with Chrome on a desktop machine, at least not on Windows 10.

Just tried Chrome Canary there on my phone and the SVG display issue is still there, Chrome Beta was also tested with the same result.

I think this is maybe an issue with the latest version of Android? What version of Android are you currently running on the 5x?

I'm on 7.0, so that may be why we differ. I'll loop in some GPU folks.

Seeing the correct behavior on Pixel XL, Chrome stable 54.0.2840.85, OS version 7.1.1.

Deleted: Screenshot_20161109-162301.png 82.5 KB

	Screenshot_20161109-162301.png 82.5 KB View Download

That's great to see! Thank you both for looking into this, your work on the Chromium project is greatly appreciated!

I was looking with a different version of OS, so it might need more investigation with a 7.1 Pixel XL.

Test team, we need someone to try to replicate this with exact hardware/OS version of the original reporter.

This does still reproduce on 7.1.

Also, this doesn't reproduce if I disable GPU raster in about:flags (again, on 7.1 on a Pixel XL).

So I'd guess there's a driver bug in 7.1 that's apparently fixed in 7.1.1.

Do we blacklist the GPU? Moving full ownership over to the GPU team.

Yeah, it sounds like we should blacklist gpu raster on 7.1.

ajuma@, are you able to post your about://gpu from your 7.1 device - we probably want to blacklist the specific driver version that ships with 7.1.

Thanks!

Is this path rendering?  Do we need to blacklist GPU raster or blacklist MSAA?

I don't have a Pixel XL, but the easiest way to test would probably be to set "GPU rasterization MSAA sample count" in chrome://flags to 0. Then we should get veto-to-software instead of veto-to-MSAA. If that fixes it, the problem is MSAA, otherwise it's something else in GPU raster.

Sorry to chime in but gave it a try and set "GPU rasterization MSAA sample count" in chrome://flags to 0 on my Pixel XL and it had the SVG images rendering properly. Reverting it back to 'default' broke them again.

Re: #18: thanks! That means we could blacklist GL_EXT_multisampled_render_to_texture on Adreno 5XX on 7.1 and it should fix the problem.

Was able to repro on my phone as well - Interestingly, force enabling GPU raster and setting msaa to 0 also fixes this issue, so it looks like the issue is specific to the msaa path rasterizer, not to GPU rasterization or other path rasterization techniques.

we blacklist GL_EXT_multisampled_render_to_texture for 5xx on android < 7.0, due to crashes. Do we want another entry, or just expand the existing one to <= 7.1? ie do we care about 7.0?

My preference would be to keep it on in 7.0.

Do we know if it works on PixelXL with 7.0?  I'm not sure if schenney meant 7.0 with Pixel XL or with Nexus 5x mentioned in #3.

I was gonna ask that too, I think 5x generation and pixel generation devices actually share their driver quite a bit (at least I've seen lots of similar bugs), so is 4xx broken as well?

(also fwiw, android versions doesn't really map to a particular driver version; eg samsung doesn't have to ship the exact same driver for the same version of android. the reported driver version doesn't work either)

Given all the problems with GL_EXT_multisampled_render_to_texture on Adreno I think it's also worth looking for any bugs in our implementation.  It's possible we are doing something wrong in command buffer or virtual contexts.

Correct me if I'm wrong, but I don't think Pixel XL shipped with anything less than 7.1, so blacklisting it in 7.0 would have no effect on that device. However, it would affect other 5xx devices, such as Galaxy S7, S7 Edge, HTC One M10, etc.

There's not really much to MSRTT from our side: we just draw to a multisampled texture, and it resolves automatically when used as a texture source. I don't think there's much we could be screwing up. Mali devices also support GL_EXT_multisampled_render_to_texture, and we haven't seen any reported problems. I'm pretty sure it's Qualcomm-specific.

#27: You're probably right, but I think it's a recurring problem on the most common Android GPU; it behooves us to investigate, try to narrow it down and file issues with QCOM.

> but I don't think Pixel XL shipped with anything less than 7.1

I honestly don't know..

aelias@: Is there any hope of getting GL driver version numbers on Android ecosystem in the future?  Does the endless forking make that infeasible?

We asked Qualcomm several years ago to add them to GL_VERSION, but the result wasn't useful and consistent enough that we ever felt it was a good idea to use them for blacklists.  As you say, the complex tree of OEM-specific forks and cherry-picks is difficult to express as a version number, nor do we have any mechanism to make vendors/OEMs increment the numbers consistently instead of just ignoring them.

Been investigating a bit - a few things I've noticed:

- This issue seems to be related to texture re-use - if I modify the Skia GrTextureProvider to always return a new texture (no re-use), the issue goes away.
- It appears that Skia renders some SVG into an intermediate, then renders that intermediate with a circular clip. In the error cases, the intermediate is not correctly overwritten, and still has its previous content.

Not sure if we can work around this issue by unbinding/rebinding the texture/framebuffer or something similar.. Will investigate a bit more.

Tried a few more things (only re-using exact sized textures, not re-using textures with pending IO) and while these did cause changes, I'm not sure they fixed anything (other than by reducing re-use).

If someone more familiar with Skia could investigate a bit more and try to narrow down what part of our MSAA path is failing on Adreno, that would be great. From the initial investigation, it seems like the driver is failing to populate the texture at all (no resolve is happening), so re-used textures are being left with their previous content.

senorblanco@, do you have any bandwidth to look into this?

In the meantime, I'll put together a blacklist CL.

This sounds similar to the pre-7.0 issues that we had on some Qualcomm devices, and I didn't have a lot of luck working around it back then. I think we should go ahead and blacklist GL_EXT_multisampled_render_to_texture on Adreno 5XX on 7.1.

Incidentally, Geoff and I searched dEQP to see if there was any coverage for this extension, and it looks like it only covers existence checks, not functional tests. So we should probably write a functional test at some point.

Sent out a CL to blacklist on 7.1. https://codereview.chromium.org/2514283002/

boliu@, in the CL which added the existing workarounds (https://codereview.chromium.org/2176703002), there were indications that multisampled render to texture seemed to work with Adreno 5xx on 7.0. Do you have a 7.0 Adreno 5xx device where you can confirm whether the bug shown here is an issue on that device? Thanks!

No I don't have one handy right now. pixel devices are hard to come by still.

I posted a bit more info on this history here a few weeks ago:
https://bugs.chromium.org/p/chromium/issues/detail?id=656320#c11

> but I don't think Pixel XL shipped with anything less than 7.1

I believe this is correct. The oldest system image from this site for pixel devices is 7.1: https://developers.google.com/android/images#marlin

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/319e63917b9f7731d260de54dcdcfec1547ab1c5

commit 319e63917b9f7731d260de54dcdcfec1547ab1c5
Author: ericrk <ericrk@chromium.org>
Date: Tue Nov 29 02:06:10 2016

Blacklist multisampled render to texture on Android 7.1 Adreno 5xx

Multisampled render to texture appears to be broken on Android 7.1 and
Adreno 5xx, similar to issues reported in Android < 7.0. This is fixed
in 7.1.1.

We should confirm that this is working in 7.0 if possible. The device
where this issue was reported (Pixel XL / Pixel) didn't ship with 7.0.

This issue appears to result in multisampled rendering failing to
produce output in cases when rendering to a texture that has already
been used in a previous render pass.

BUG= 663811 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2514283002
Cr-Commit-Position: refs/heads/master@{#434829}

[modify] https://crrev.com/319e63917b9f7731d260de54dcdcfec1547ab1c5/gpu/config/gpu_driver_bug_list_json.cc

This should be fixed by #37, re-open if this is still being seen.