Why limit max texture size to 4096 on Android?

[Roger Yi]

According to this commit: https://codereview.chromium.org/1761593002, max texture size is limit to 4096 on all Android devices instead of use real max texture size from GL context, but I cann't access the bug (https://bugs.chromium.org/p/chromium/issues/detail?id=591239), curious to know the reason.

This commit may cause performance regression on this demo FishIETank (https://testdrive-archive.azurewebsites.net/Performance/FishIETank/Default.html), the fish is using a 4912x951 png, and force to tiling even the real maxture txture size is large than 4096, and can avoid tiling before the commit.

[dan...@chromium.org]

Drivers were advertising a max size that was so large that they'd then freeze when the texture of that size was actually created. 4096 was arbitrarily chosen afaict, it may not be the perfect number.

[Kai Ninomiya]

If we want to relax that restriction, I think we had another workaround somewhere which limited the total area of the texture to 4096*4096 pixels (16 Mi), or to (max viewport width * max viewport height) or something along those lines. I didn't look deeply at the original bug, but that might work here too.

[Victor Miura]

Even if we increase the artificial size, some devices would still have such limits.  What is focring tiling, is it in the benchmark or in Chromium?

[Roger Yi]

在 2017年12月23日星期六 UTC+8上午2:43:13，Victor Miura写道：

Even if we increase the artificial size, some devices would still have such limits.  What is focring tiling, is it in the benchmark or in Chromium?

In Chromium, SkGpuDevice::shouldTileImageID will return true. 

[Roger Yi]

在 2017年12月22日星期五 UTC+8下午11:56:27，danakj写道：

Drivers were advertising a max size that was so large that they'd then freeze when the texture of that size was actually created. 4096 was arbitrarily chosen afaict, it may not be the perfect number.

Maybe we can use this limit on buggy devices instead of on all Android devices? 

[Bo Liu]

Did a bit of digging. The value of 4096 came from mac GPU: https://codereview.chromium.org/9950072 Then android just reused the same workaround. And now the mac workarounds have all been removed since the affected mac os version is no longer supported by chrome.

Android just took 4096 from mac, so pretty arbitrary. But if we were to re-evaluate for android, I think it makes more sense to make it smaller rather than bigger. I don't know what that skia check is for though, and if it's important for perf.

On Fri, Dec 22, 2017 at 10:12 AM, Kai Ninomiya <kai...@google.com> wrote:

If we want to relax that restriction, I think we had another workaround somewhere which limited the total area of the texture to 4096*4096 pixels (16 Mi), or to (max viewport width * max viewport height) or something along those lines. I didn't look deeply at the original bug, but that might work here too.

Note using viewport dimensions usually doesn't work well on android webview. Webview's "viewport" isn't limited to screen size and can get arbitrarily large, which was how it was even possible to hit the max texture size reported by the driver in that bug.

On Fri, Dec 22, 2017 at 9:55 PM, Roger Yi <roge...@gmail.com> wrote:

在 2017年12月22日星期五 UTC+8下午11:56:27，danakj写道：

Drivers were advertising a max size that was so large that they'd then freeze when the texture of that size was actually created. 4096 was arbitrarily chosen afaict, it may not be the perfect number.

Maybe we can use this limit on buggy devices instead of on all Android devices?

The buggy driver was qualcomm on a nexus 6, so relatively modern device. Blacklisting only qualcomm doesn't do a whole lot since it's probably the market leader.

[Brian Osman]

The skia check is trying to limit usage of texture cache - when a large bitmap is being drawn, but clipping or the sub-rect being used is significantly smaller than the entire image, we switch to a tiled draw that (logically) chops the bitmap into a grid, then only uploads and draws the tiles that are needed. If a client is drawing a zoomed view of a very large image, for example, this is a win. In the benchmark being discussed here, it's probably not helpful, because it's a big sprite sheet, and all parts of it are in-use.

--
You received this message because you are subscribed to the Google Groups "Graphics-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to graphics-dev+unsubscribe@chromium.org.

[Brian Salomon]

I believe in this case Skia is not chopping the source image to reduce texture memory usage but rather because we think the max texture size is 4096 and the sprite sheet is a bit larger than that.

To unsubscribe from this group and stop receiving emails from it, send an email to graphics-dev...@chromium.org.

[Roger Yi]

在 2018年1月3日星期三 UTC+8上午3:44:11，Brian Salomon写道：

I believe in this case Skia is not chopping the source image to reduce texture memory usage but rather because we think the max texture size is 4096 and the sprite sheet is a bit larger than that.

You are correct, the fish is using a 4912x951 png, and 4912 > 4096, so it is tiling in Skia on all Android devices. 

The performance regression is caused by :

1. Before the commit, draw a fish on devices support max texture size > 4096 will only need one drawBitmap;

2. After the commit, draw a fish on all devices may need two or four drawTiledBitmap when a fish cross tiling grids;