Use the GrCacheable ID to eliminate the need for notifications to GrGpuGL when textures and RTs are…

Use the GrCacheable ID to eliminate the need for notifications to GrGpuGL when textures and RTs are deleted.

Also, rename GrCacheable::getGenerationID() to getInstanceID() since it doesn't behave like other "generation" IDs.

Committed: https://skia.googlesource.com/skia/+/91bdbcdbbdf5cdf0fdb4518a0d30206c964cfdf6

[bsalomon, 2014-07-08 19:02:28]

We have these notifications simply because a memory address could be reused.
This change is just an attempt to reduce the complexity a little bit. I used
"instanceID" to make this ID distinguished from both generation IDs that change
when the contents change and GL IDs.

[jvanverth1, 2014-07-08 19:35:43]

Well, let's hope that we never have over 4 billion cacheable objects. :)

LGTM + comment

https://codereview.chromium.org/376703009/diff/20001/src/gpu/GrCacheable.cpp
File src/gpu/GrCacheable.cpp (right):

https://codereview.chromium.org/376703009/diff/20001/src/gpu/GrCacheable.cpp#...
src/gpu/GrCacheable.cpp:12: static int32_t gCacheableID;
Since 0 means 'no entry' in fHWBoundRenderTargetInstanceID, etc., shouldn't this
be initialized to 0 just to make sure we (practically) never hit it?

[bsalomon, 2014-07-08 19:39:12]

https://codereview.chromium.org/376703009/diff/20001/src/gpu/GrCacheable.cpp
File src/gpu/GrCacheable.cpp (right):

https://codereview.chromium.org/376703009/diff/20001/src/gpu/GrCacheable.cpp#...
src/gpu/GrCacheable.cpp:12: static int32_t gCacheableID;
On 2014/07/08 19:35:43, jvanverth1 wrote:
> Since 0 means 'no entry' in fHWBoundRenderTargetInstanceID, etc., shouldn't
this
> be initialized to 0 just to make sure we (practically) never hit it?

It is! All static POD types are initialized to 0.

Also, the loop below handles the unlikely case of wrapping back to 0 (though we
might have problems with duplicate IDs at that point).

[bsalomon, 2014-07-08 19:43:01]

The CQ bit was checked by bsalomon@google.com

[commit-bot: I haz the power, 2014-07-08 19:43:16]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/bsalomon@google.com/376703009/20001

[commit-bot: I haz the power, 2014-07-08 20:10:22]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  Build-Mac10.8-Clang-x86-Release-Trybot on tryserver.skia
(http://108.170.220.76:10117/builders/Build-Mac10.8-Clang-x86-Release-Trybot/b...)
  Build-Ubuntu13.10-Clang-x86_64-Debug-Trybot on tryserver.skia
(http://108.170.220.76:10117/builders/Build-Ubuntu13.10-Clang-x86_64-Debug-Try...)
  Build-Ubuntu13.10-GCC4.8-x86_64-Release-Trybot on tryserver.skia
(http://108.170.220.76:10117/builders/Build-Ubuntu13.10-GCC4.8-x86_64-Release-...)

[commit-bot: I haz the power, 2014-07-08 20:19:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-07-08 20:19:32]

Try jobs failed on following builders:
  Build-Mac10.8-Clang-x86-Release-Trybot on tryserver.skia
(http://108.170.220.76:10117/builders/Build-Mac10.8-Clang-x86-Release-Trybot/b...)

[bsalomon, 2014-07-17 16:14:19]

The CQ bit was checked by bsalomon@google.com

[commit-bot: I haz the power, 2014-07-17 16:15:15]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/bsalomon@google.com/376703009/40001

[commit-bot: I haz the power, 2014-07-17 16:28:12]

Change committed as 91bdbcdbbdf5cdf0fdb4518a0d30206c964cfdf6

[robertphillips, 2014-07-20 16:20:41]

A revert of this CL has been created in
https://codereview.chromium.org/405023003/ by robertphillips@google.com.

The reason for reverting is: Trying to unblock roll wedged on 64 bit intrinsic
call on XP.