When bmp is not cached don't upload as index8 format.

When bmp is not cached don't upload as index8 format.

Committed: https://skia.googlesource.com/skia/+/e79a2dab91a90e26b13bc1ec9b8c6264a1ab22e4

[bsalomon, 2014-10-23 20:17:36]

bsalomon@google.com changed reviewers:
+ robertphillips@google.com

[bsalomon, 2014-10-23 20:17:37]

This might argue for a more general way to create a texture that is removed from
the cache ASAP. Right now our only choices are scratch or reusable cached
texture.

The new behavior matches what we do for ETC1.

[robertphillips, 2014-10-24 12:15:47]

lgtm. So the problem was that, since we don't have scratch index8 textures, all
the volatile index8 textures were filling up VRAM? And, with this CL, the
volatile index8 textures are now promoted to 32bit scratch textures and thus
properly drive flushes?

https://codereview.chromium.org/673883002/diff/1/src/gpu/SkGr.cpp
File src/gpu/SkGr.cpp (right):

https://codereview.chromium.org/673883002/diff/1/src/gpu/SkGr.cpp#newcode314
src/gpu/SkGr.cpp:314: SkAutoMalloc storage(imageSize);
Is this memset necessary?

[bsalomon, 2014-10-24 13:46:07]

They could still drive flushes, but if the bitmap was changing frequently we
could wind up polluting the cache with lots of variants of the same texture. I
don't know that this was happening in practice. I kind of doubt Chrome ever
marks index8 bmps as volatile. I noticed this while working on something else.

I think a better solution would be to indicate on the texture that it should be
freed ASAP. We could do this with all volatile objects and then the cache could
decide whether to convert to scratch or not at that time (if it has a scratch
key).

https://codereview.chromium.org/673883002/diff/1/src/gpu/SkGr.cpp
File src/gpu/SkGr.cpp (right):

https://codereview.chromium.org/673883002/diff/1/src/gpu/SkGr.cpp#newcode314
src/gpu/SkGr.cpp:314: SkAutoMalloc storage(imageSize);
On 2014/10/24 12:15:47, robertphillips wrote:
> Is this memset necessary?

Oops, no, leftover from debugging something.

[bsalomon, 2014-10-24 18:31:28]

The CQ bit was checked by bsalomon@google.com

[commit-bot: I haz the power, 2014-10-24 18:31:55]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/673883002/20001

[commit-bot: I haz the power, 2014-10-24 19:43:11]

Committed patchset #2 (id:20001) as e79a2dab91a90e26b13bc1ec9b8c6264a1ab22e4