Refactor to separate backend object lifecycle and GpuResource budget decision

Refactor to separate backend object lifecycle and GpuResource budget decision

Refactor GrGpuResource to contain two different pieces of state:
 a) instance is budgeted or not budgeted
 b) instance references wrapped backend objects or not

The "object lifecycle" was also attached to backend object
handles (ids), which made the code a bit unclear. Backend objects
would be associated with GrGpuResource::LifeCycle, even though
GrGpuResource::LifeCycle refers to the GpuResource, and individual
backend objects in one GpuResource might be governed with different
"lifecycle".

Mark the budgeted/not budgeted with SkBudgeted::kYes, SkBudgeted::kNo.
This was previously GrGpuResource::kCached_LifeCycle,
GrGpuResource::kUncached_LifeCycle.

Mark the "references wrapped object" with boolean. This was previously
GrGpuResource::kBorrowed_LifeCycle,
GrGpuResource::kAdopted_LifeCycle for GrGpuResource.

Associate the backend object ownership status with 
GrBackendObjectOwnership for the backend object handles.

The resource type leaf constuctors, such has GrGLTexture or
GrGLTextureRenderTarget take "budgeted" parameter. This parameter
is passed to GrGpuResource::registerWithCache().

The resource type intermediary constructors, such as GrGLTexture
constructors for class GrGLTextureRenderTarget do not take "budgeted"
parameters, intermediary construtors do not call registerWithCache.

Removes the need for tagging GrGpuResource -derived subclass
constructors with "Derived" parameter.

Makes instances that wrap backend objects be registered with
a new function GrGpuResource::registerWithCacheWrapped().

Removes "budgeted" parameter from classes such as StencilAttahment, as
they are always cached and never wrap any external backend objects.

Removes the use of concept "external" from the member function names.
The API refers to the objects as "wrapped", so make all related
functions use the term consistently.

No change in functionality. Resources referencing wrapped objects are
always inserted to the cache with budget decision kNo.

BUG=594928
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1862043002

Committed: https://skia.googlesource.com/skia/+/2e6055b3ea14a04fcde1ac1974a70bf00b1e295b

[Kimmo Kinnunen, 2016-04-06 13:19:47]

Description was changed from

==========
Refactor to separate backend object lifecycle and GpuResource budget decision

Refactor GrGpuResource to contain two different pieces of state:
 a) instance is budgeted or not budgeted
 b) instance references wrapped backend objects or not

The "object lifecycle" was also attached to backend object
handles (ids), which made the code a bit unclear. Backend objects
would be associated with GrGpuResource::LifeCycle, even though
GrGpuResource::LifeCycle refers to the GpuResource, and individual
backend objects in one GpuResource might be governed with different
"lifecycle".

Mark the budgeted/not budgeted with SkBudgeted::kYes, SkBudgeted::kNo.
This was previously GrGpuResource::kCached_LifeCycle,
GrGpuResource::kUncached_LifeCycle.

Mark the "references wrapped object" with boolean. This was previously
GrGpuResource::kBorrowed_LifeCycle,
GrGpuResource::kAdopted_LifeCycle for GrGpuResource.

Associate the wrapped object lifecycle with GrBackendObjectLifeCycle for
the backend object handles.

The resource type leaf constuctors, such has GrGLTexture or
GrGLTextureRenderTarget take "budgeted" parameter. This parameter
is passed to GrGpuResource::registerWithCache().

The resource type intermediary constructors, such as GrGLTexture
constructors for class GrGLTextureRenderTarget do not take "budgeted"
parameters, intermediary construtors do not call registerWithCache.

Removes the need for tagging GrGpuResource -derived subclass
constructors with "Derived" parameter.

Makes instances that wrap backend objects be registered with
a new function GrGpuResource::registerWithCacheWrapped().

Removes "budgeted" parameter from classes such as StencilAttahment, as
they are always cached and never wrap any external backend objects.

Removes the use of concept "external" from the member function names.
The API refers to the objects as "wrapped", so make all related
functions use the term consistently.

No change in functionality. Resources referencing wrapped objects are
always inserted to the cache with budget decision kNo.

BUG=594928
==========

to

==========
Refactor to separate backend object lifecycle and GpuResource budget decision

Refactor GrGpuResource to contain two different pieces of state:
 a) instance is budgeted or not budgeted
 b) instance references wrapped backend objects or not

The "object lifecycle" was also attached to backend object
handles (ids), which made the code a bit unclear. Backend objects
would be associated with GrGpuResource::LifeCycle, even though
GrGpuResource::LifeCycle refers to the GpuResource, and individual
backend objects in one GpuResource might be governed with different
"lifecycle".

Mark the budgeted/not budgeted with SkBudgeted::kYes, SkBudgeted::kNo.
This was previously GrGpuResource::kCached_LifeCycle,
GrGpuResource::kUncached_LifeCycle.

Mark the "references wrapped object" with boolean. This was previously
GrGpuResource::kBorrowed_LifeCycle,
GrGpuResource::kAdopted_LifeCycle for GrGpuResource.

Associate the wrapped object lifecycle with GrBackendObjectLifeCycle for
the backend object handles.

The resource type leaf constuctors, such has GrGLTexture or
GrGLTextureRenderTarget take "budgeted" parameter. This parameter
is passed to GrGpuResource::registerWithCache().

The resource type intermediary constructors, such as GrGLTexture
constructors for class GrGLTextureRenderTarget do not take "budgeted"
parameters, intermediary construtors do not call registerWithCache.

Removes the need for tagging GrGpuResource -derived subclass
constructors with "Derived" parameter.

Makes instances that wrap backend objects be registered with
a new function GrGpuResource::registerWithCacheWrapped().

Removes "budgeted" parameter from classes such as StencilAttahment, as
they are always cached and never wrap any external backend objects.

Removes the use of concept "external" from the member function names.
The API refers to the objects as "wrapped", so make all related
functions use the term consistently.

No change in functionality. Resources referencing wrapped objects are
always inserted to the cache with budget decision kNo.

BUG=594928
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

[Kimmo Kinnunen, 2016-04-06 14:28:14]

kkinnunen@nvidia.com changed reviewers:
+ bsalomon@google.com

[Kimmo Kinnunen, 2016-04-06 14:28:15]

This should be a no-change refactoring.
It should be usable with or without the fbo caching thing, but I'm not sure how
you feel about using it if it's not needed.
This is separated in order to make the fbo caching patch simpler.

[bsalomon, 2016-04-19 14:37:46]

Sorry for the slow review. I like this direction.

https://codereview.chromium.org/1862043002/diff/20001/include/gpu/GrGpuResour...
File include/gpu/GrGpuResource.h (right):

https://codereview.chromium.org/1862043002/diff/20001/include/gpu/GrGpuResour...
include/gpu/GrGpuResource.h:269: virtual void computeScratchKey(GrScratchKey*
scratchKey) const { };
Can this be private? Seems like only registerWithCache needs to call it.

https://codereview.chromium.org/1862043002/diff/20001/include/gpu/GrTypes.h
File include/gpu/GrTypes.h (right):

https://codereview.chromium.org/1862043002/diff/20001/include/gpu/GrTypes.h#n...
include/gpu/GrTypes.h:428: enum class GrBackendObjectLifeCycle {
Seems a bit concusing that we call this BackendObjectLifeCycle but it isn't just
used for wrapped backend objects and has a kInternal value. Also, even though I
created it I never loved the term LifeCycle. Would GrResourceOwnership make more
sense here?


It also seems like this and GrWrapOwnership are mostly redundant, this just adds
the kInternal value.. What about unifying them and making public wrap methods
fail if kInternal is passed?

[Kimmo Kinnunen, 2016-04-20 12:04:55]

https://codereview.chromium.org/1862043002/diff/20001/include/gpu/GrGpuResour...
File include/gpu/GrGpuResource.h (right):

https://codereview.chromium.org/1862043002/diff/20001/include/gpu/GrGpuResour...
include/gpu/GrGpuResource.h:269: virtual void computeScratchKey(GrScratchKey*
scratchKey) const { };
On 2016/04/19 14:37:46, bsalomon wrote:
> Can this be private? Seems like only registerWithCache needs to call it.

Done.

https://codereview.chromium.org/1862043002/diff/20001/include/gpu/GrTypes.h
File include/gpu/GrTypes.h (right):

https://codereview.chromium.org/1862043002/diff/20001/include/gpu/GrTypes.h#n...
include/gpu/GrTypes.h:428: enum class GrBackendObjectLifeCycle {
On 2016/04/19 14:37:46, bsalomon wrote:
> Seems a bit concusing that we call this BackendObjectLifeCycle but it isn't
just
> used for wrapped backend objects and has a kInternal value.

The "backend object" here means GL object or Vulkan object, not "wrapped"
status. I'll update the comments further to make the distinction.

 "backend object" -> GL int
 "resource" -> Skia resource cache item

It is used for all backend object references, where the ownership is
customizable.
Renamed it to GrBackendObjectOwnership.

Maybe this "wrapped" vs "this is resource should be destroyed" confusion is not
going away unless the interface is factored to its logical but verbose
conclusion. 

Is the new code taking it too far?

> Would GrResourceOwnership make more sense here?

Originally I moved away from "Resource", as it would imply GrGpuResource
ownership, which GrBackendObjectOwnership is not. 


> It also seems like this and GrWrapOwnership are mostly redundant, this just
adds
> the kInternal value.. What about unifying them and making public wrap methods
> fail if kInternal is passed?

Personally I prefer them separate, as they represent different things. I don't
see much savings from removing one. Anyhow, I made the thing even more verbose,
and at the same time nullifying this unification opportunity.

I think GrWrapOwnership::kAdopt_GrWrapOwnership is the source of complexity
here. It does not seem very consistent with the rest of the API, as such
semantics are not available for all the wrap calls. One way to simplify things
is to remove it, if only possible.

[Kimmo Kinnunen, 2016-04-20 12:04:55]

https://codereview.chromium.org/1862043002/diff/20001/include/gpu/GrGpuResour...
File include/gpu/GrGpuResource.h (right):

https://codereview.chromium.org/1862043002/diff/20001/include/gpu/GrGpuResour...
include/gpu/GrGpuResource.h:269: virtual void computeScratchKey(GrScratchKey*
scratchKey) const { };
On 2016/04/19 14:37:46, bsalomon wrote:
> Can this be private? Seems like only registerWithCache needs to call it.

Done.

https://codereview.chromium.org/1862043002/diff/20001/include/gpu/GrTypes.h
File include/gpu/GrTypes.h (right):

https://codereview.chromium.org/1862043002/diff/20001/include/gpu/GrTypes.h#n...
include/gpu/GrTypes.h:428: enum class GrBackendObjectLifeCycle {
On 2016/04/19 14:37:46, bsalomon wrote:
> Seems a bit concusing that we call this BackendObjectLifeCycle but it isn't
just
> used for wrapped backend objects and has a kInternal value.

The "backend object" here means GL object or Vulkan object, not "wrapped"
status. I'll update the comments further to make the distinction.

 "backend object" -> GL int
 "resource" -> Skia resource cache item

It is used for all backend object references, where the ownership is
customizable.
Renamed it to GrBackendObjectOwnership.

Maybe this "wrapped" vs "this is resource should be destroyed" confusion is not
going away unless the interface is factored to its logical but verbose
conclusion. 

Is the new code taking it too far?

> Would GrResourceOwnership make more sense here?

Originally I moved away from "Resource", as it would imply GrGpuResource
ownership, which GrBackendObjectOwnership is not. 


> It also seems like this and GrWrapOwnership are mostly redundant, this just
adds
> the kInternal value.. What about unifying them and making public wrap methods
> fail if kInternal is passed?

Personally I prefer them separate, as they represent different things. I don't
see much savings from removing one. Anyhow, I made the thing even more verbose,
and at the same time nullifying this unification opportunity.

I think GrWrapOwnership::kAdopt_GrWrapOwnership is the source of complexity
here. It does not seem very consistent with the rest of the API, as such
semantics are not available for all the wrap calls. One way to simplify things
is to remove it, if only possible.

[Kimmo Kinnunen, 2016-04-20 12:10:51]

Description was changed from

==========
Refactor to separate backend object lifecycle and GpuResource budget decision

Refactor GrGpuResource to contain two different pieces of state:
 a) instance is budgeted or not budgeted
 b) instance references wrapped backend objects or not

The "object lifecycle" was also attached to backend object
handles (ids), which made the code a bit unclear. Backend objects
would be associated with GrGpuResource::LifeCycle, even though
GrGpuResource::LifeCycle refers to the GpuResource, and individual
backend objects in one GpuResource might be governed with different
"lifecycle".

Mark the budgeted/not budgeted with SkBudgeted::kYes, SkBudgeted::kNo.
This was previously GrGpuResource::kCached_LifeCycle,
GrGpuResource::kUncached_LifeCycle.

Mark the "references wrapped object" with boolean. This was previously
GrGpuResource::kBorrowed_LifeCycle,
GrGpuResource::kAdopted_LifeCycle for GrGpuResource.

Associate the wrapped object lifecycle with GrBackendObjectLifeCycle for
the backend object handles.

The resource type leaf constuctors, such has GrGLTexture or
GrGLTextureRenderTarget take "budgeted" parameter. This parameter
is passed to GrGpuResource::registerWithCache().

The resource type intermediary constructors, such as GrGLTexture
constructors for class GrGLTextureRenderTarget do not take "budgeted"
parameters, intermediary construtors do not call registerWithCache.

Removes the need for tagging GrGpuResource -derived subclass
constructors with "Derived" parameter.

Makes instances that wrap backend objects be registered with
a new function GrGpuResource::registerWithCacheWrapped().

Removes "budgeted" parameter from classes such as StencilAttahment, as
they are always cached and never wrap any external backend objects.

Removes the use of concept "external" from the member function names.
The API refers to the objects as "wrapped", so make all related
functions use the term consistently.

No change in functionality. Resources referencing wrapped objects are
always inserted to the cache with budget decision kNo.

BUG=594928
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

to

==========
Refactor to separate backend object lifecycle and GpuResource budget decision

Refactor GrGpuResource to contain two different pieces of state:
 a) instance is budgeted or not budgeted
 b) instance references wrapped backend objects or not

The "object lifecycle" was also attached to backend object
handles (ids), which made the code a bit unclear. Backend objects
would be associated with GrGpuResource::LifeCycle, even though
GrGpuResource::LifeCycle refers to the GpuResource, and individual
backend objects in one GpuResource might be governed with different
"lifecycle".

Mark the budgeted/not budgeted with SkBudgeted::kYes, SkBudgeted::kNo.
This was previously GrGpuResource::kCached_LifeCycle,
GrGpuResource::kUncached_LifeCycle.

Mark the "references wrapped object" with boolean. This was previously
GrGpuResource::kBorrowed_LifeCycle,
GrGpuResource::kAdopted_LifeCycle for GrGpuResource.

Associate the backend object ownership status with 
GrBackendObjectOwnership for the backend object handles.

The resource type leaf constuctors, such has GrGLTexture or
GrGLTextureRenderTarget take "budgeted" parameter. This parameter
is passed to GrGpuResource::registerWithCache().

The resource type intermediary constructors, such as GrGLTexture
constructors for class GrGLTextureRenderTarget do not take "budgeted"
parameters, intermediary construtors do not call registerWithCache.

Removes the need for tagging GrGpuResource -derived subclass
constructors with "Derived" parameter.

Makes instances that wrap backend objects be registered with
a new function GrGpuResource::registerWithCacheWrapped().

Removes "budgeted" parameter from classes such as StencilAttahment, as
they are always cached and never wrap any external backend objects.

Removes the use of concept "external" from the member function names.
The API refers to the objects as "wrapped", so make all related
functions use the term consistently.

No change in functionality. Resources referencing wrapped objects are
always inserted to the cache with budget decision kNo.

BUG=594928
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

[Kimmo Kinnunen, 2016-04-20 13:59:03]

https://codereview.chromium.org/1862043002/diff/60001/include/gpu/GrTypes.h
File include/gpu/GrTypes.h (right):

https://codereview.chromium.org/1862043002/diff/60001/include/gpu/GrTypes.h#n...
include/gpu/GrTypes.h:428: enum class GrBackendObjectOwnership : bool {
I guess now this is quite similar to below..

https://codereview.chromium.org/1862043002/diff/60001/include/gpu/GrTypes.h#n...
include/gpu/GrTypes.h:504: enum GrWrapOwnership {
.. similar to this.
The docstrings will be confusing.
Your call.

[bsalomon, 2016-04-20 15:48:03]

https://codereview.chromium.org/1862043002/diff/60001/include/gpu/GrTypes.h
File include/gpu/GrTypes.h (right):

https://codereview.chromium.org/1862043002/diff/60001/include/gpu/GrTypes.h#n...
include/gpu/GrTypes.h:428: enum class GrBackendObjectOwnership : bool {
On 2016/04/20 13:59:03, Kimmo Kinnunen wrote:
> I guess now this is quite similar to below..

Looking at the latest CL I think it makes sense to keep it separate. However,
can it be moved to GrGpuResource.h or GrTypesPriv.h?

[Kimmo Kinnunen, 2016-04-21 08:08:45]

On 2016/04/20 15:48:03, bsalomon wrote:
>
https://codereview.chromium.org/1862043002/diff/60001/include/gpu/GrTypes.h#n...
> include/gpu/GrTypes.h:428: enum class GrBackendObjectOwnership : bool {
> On 2016/04/20 13:59:03, Kimmo Kinnunen wrote:
> > I guess now this is quite similar to below..
> 
> Looking at the latest CL I think it makes sense to keep it separate. However,
> can it be moved to GrGpuResource.h or GrTypesPriv.h?

Done.

[bsalomon, 2016-04-21 12:58:41]

lgtm

[Kimmo Kinnunen, 2016-04-22 08:25:50]

On 2016/04/21 12:58:41, bsalomon wrote:
> lgtm

I had to do small changes that I forgot from this refactored patch. I'm taking
the liberty to push CQ, I hope it's ok. Feel free to revert otherwise.

[Kimmo Kinnunen, 2016-04-22 08:25:59]

The CQ bit was checked by kkinnunen@nvidia.com

[Kimmo Kinnunen, 2016-04-22 08:26:00]

The patchset sent to the CQ was uploaded after l-g-t-m from bsalomon@google.com
Link to the patchset:
https://chromiumcodereview.appspot.com/1862043002/#ps100001 (title: "rebase and
small fixes")

[commit-bot: I haz the power, 2016-04-22 08:26:04]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1862043002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1862043002/100001

[commit-bot: I haz the power, 2016-04-22 08:27:34]

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

[commit-bot: I haz the power, 2016-04-22 08:27:35]

Try jobs failed on following builders:
  Build-Mac-Clang-x86_64-Release-Trybot on client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Mac-Clang-x86_...)
  Build-Ubuntu-Clang-x86_64-Debug-Trybot on client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-Clang-x...)
  Build-Ubuntu-GCC-x86_64-Release-Trybot on client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-GCC-x86...)

[Kimmo Kinnunen, 2016-04-22 08:28:42]

https://chromiumcodereview.appspot.com/1862043002/diff/100001/src/gpu/gl/GrGL...
File src/gpu/gl/GrGLRenderTarget.cpp (right):

https://chromiumcodereview.appspot.com/1862043002/diff/100001/src/gpu/gl/GrGL...
src/gpu/gl/GrGLRenderTarget.cpp:163: // Direct GrGLRenderTarget instances are
always created with CreateWrapped.
This changed..

https://chromiumcodereview.appspot.com/1862043002/diff/100001/src/gpu/gl/GrGL...
File src/gpu/gl/GrGLTexture.cpp (right):

https://chromiumcodereview.appspot.com/1862043002/diff/100001/src/gpu/gl/GrGL...
src/gpu/gl/GrGLTexture.cpp:64: fTextureIDOwnership = idDesc.fOwnership;
this changed..

https://chromiumcodereview.appspot.com/1862043002/diff/100001/src/gpu/gl/GrGL...
File src/gpu/gl/GrGLTextureRenderTarget.cpp (right):

https://chromiumcodereview.appspot.com/1862043002/diff/100001/src/gpu/gl/GrGL...
src/gpu/gl/GrGLTextureRenderTarget.cpp:41: bool
GrGLTextureRenderTarget::canAttemptStencilAttachment() const {
this changed.

[Kimmo Kinnunen, 2016-04-22 08:31:51]

The CQ bit was checked by kkinnunen@nvidia.com

[Kimmo Kinnunen, 2016-04-22 08:31:52]

The patchset sent to the CQ was uploaded after l-g-t-m from bsalomon@google.com
Link to the patchset: https://codereview.chromium.org/1862043002/#ps120001
(title: "fix a compile error due to unused parameter")

[commit-bot: I haz the power, 2016-04-22 08:31:58]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1862043002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1862043002/120001

[commit-bot: I haz the power, 2016-04-22 08:33:27]

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

[commit-bot: I haz the power, 2016-04-22 08:33:28]

Try jobs failed on following builders:
  Build-Mac-Clang-x86_64-Release-Trybot on client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Mac-Clang-x86_...)

[Kimmo Kinnunen, 2016-04-22 08:39:17]

The CQ bit was checked by kkinnunen@nvidia.com

[Kimmo Kinnunen, 2016-04-22 08:39:18]

The patchset sent to the CQ was uploaded after l-g-t-m from bsalomon@google.com
Link to the patchset: https://codereview.chromium.org/1862043002/#ps140001
(title: "fix unrelated GrBuffer::onGpuMemorySize() lack of override keyword
compile error")

[commit-bot: I haz the power, 2016-04-22 08:39:27]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1862043002/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1862043002/140001

[commit-bot: I haz the power, 2016-04-22 08:48:33]

Description was changed from

==========
Refactor to separate backend object lifecycle and GpuResource budget decision

Refactor GrGpuResource to contain two different pieces of state:
 a) instance is budgeted or not budgeted
 b) instance references wrapped backend objects or not

The "object lifecycle" was also attached to backend object
handles (ids), which made the code a bit unclear. Backend objects
would be associated with GrGpuResource::LifeCycle, even though
GrGpuResource::LifeCycle refers to the GpuResource, and individual
backend objects in one GpuResource might be governed with different
"lifecycle".

Mark the budgeted/not budgeted with SkBudgeted::kYes, SkBudgeted::kNo.
This was previously GrGpuResource::kCached_LifeCycle,
GrGpuResource::kUncached_LifeCycle.

Mark the "references wrapped object" with boolean. This was previously
GrGpuResource::kBorrowed_LifeCycle,
GrGpuResource::kAdopted_LifeCycle for GrGpuResource.

Associate the backend object ownership status with 
GrBackendObjectOwnership for the backend object handles.

The resource type leaf constuctors, such has GrGLTexture or
GrGLTextureRenderTarget take "budgeted" parameter. This parameter
is passed to GrGpuResource::registerWithCache().

The resource type intermediary constructors, such as GrGLTexture
constructors for class GrGLTextureRenderTarget do not take "budgeted"
parameters, intermediary construtors do not call registerWithCache.

Removes the need for tagging GrGpuResource -derived subclass
constructors with "Derived" parameter.

Makes instances that wrap backend objects be registered with
a new function GrGpuResource::registerWithCacheWrapped().

Removes "budgeted" parameter from classes such as StencilAttahment, as
they are always cached and never wrap any external backend objects.

Removes the use of concept "external" from the member function names.
The API refers to the objects as "wrapped", so make all related
functions use the term consistently.

No change in functionality. Resources referencing wrapped objects are
always inserted to the cache with budget decision kNo.

BUG=594928
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

to

==========
Refactor to separate backend object lifecycle and GpuResource budget decision

Refactor GrGpuResource to contain two different pieces of state:
 a) instance is budgeted or not budgeted
 b) instance references wrapped backend objects or not

The "object lifecycle" was also attached to backend object
handles (ids), which made the code a bit unclear. Backend objects
would be associated with GrGpuResource::LifeCycle, even though
GrGpuResource::LifeCycle refers to the GpuResource, and individual
backend objects in one GpuResource might be governed with different
"lifecycle".

Mark the budgeted/not budgeted with SkBudgeted::kYes, SkBudgeted::kNo.
This was previously GrGpuResource::kCached_LifeCycle,
GrGpuResource::kUncached_LifeCycle.

Mark the "references wrapped object" with boolean. This was previously
GrGpuResource::kBorrowed_LifeCycle,
GrGpuResource::kAdopted_LifeCycle for GrGpuResource.

Associate the backend object ownership status with 
GrBackendObjectOwnership for the backend object handles.

The resource type leaf constuctors, such has GrGLTexture or
GrGLTextureRenderTarget take "budgeted" parameter. This parameter
is passed to GrGpuResource::registerWithCache().

The resource type intermediary constructors, such as GrGLTexture
constructors for class GrGLTextureRenderTarget do not take "budgeted"
parameters, intermediary construtors do not call registerWithCache.

Removes the need for tagging GrGpuResource -derived subclass
constructors with "Derived" parameter.

Makes instances that wrap backend objects be registered with
a new function GrGpuResource::registerWithCacheWrapped().

Removes "budgeted" parameter from classes such as StencilAttahment, as
they are always cached and never wrap any external backend objects.

Removes the use of concept "external" from the member function names.
The API refers to the objects as "wrapped", so make all related
functions use the term consistently.

No change in functionality. Resources referencing wrapped objects are
always inserted to the cache with budget decision kNo.

BUG=594928
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...

Committed:
https://skia.googlesource.com/skia/+/2e6055b3ea14a04fcde1ac1974a70bf00b1e295b
==========

[commit-bot: I haz the power, 2016-04-22 08:48:34]

Committed patchset #8 (id:140001) as
https://skia.googlesource.com/skia/+/2e6055b3ea14a04fcde1ac1974a70bf00b1e295b