Split cache-specific fields out of GrTextureDesc

This CL makes the GrTextureDesc class more coherent by isolating the cache-specific fields in their own struct (GrCacheData). Now code that doesn't use the cache need not concern itself with extraneous variables.

[bsalomon, 2012-08-13 13:48:24]

Overall LGTM.

http://codereview.appspot.com/6448143/diff/2001/include/gpu/GrTypes.h
File include/gpu/GrTypes.h (right):

http://codereview.appspot.com/6448143/diff/2001/include/gpu/GrTypes.h#newcode516
include/gpu/GrTypes.h:516: * All scratch resources should be Unrestricted so
they can be used
It seems like we already are pretty prolific with our naming around cache keys.
Should we just call this the kScratch_ResourceDomain? Also, I wonder whether it
makes sense to allow any ID other than the scratch ID in this domain. It just
seems like unless we're going through the same key-generation code we shouldn't
be playing in the same pool because we will eventually collide. And going
through the same key-generation code kinda is what a domain is. Do we have a
reason for allowing non-scratch IDs in the unrestricted domain? Or is this a
goal for a later change?

http://codereview.appspot.com/6448143/diff/2001/include/gpu/GrTypes.h#newcode523
include/gpu/GrTypes.h:523: // of these, you should definitely have a key
(or use the scratch key). ?

[robertphillips, 2012-08-13 14:14:51]

http://codereview.appspot.com/6448143/diff/2001/include/gpu/GrTypes.h
File include/gpu/GrTypes.h (right):

http://codereview.appspot.com/6448143/diff/2001/include/gpu/GrTypes.h#newcode516
include/gpu/GrTypes.h:516: * All scratch resources should be Unrestricted so
they can be used
Done - I don't think we will want individual domains hoarding scratch textures.
Short term we will need to allow non-scratch ID's to co-exist with the scratch
domain. Once we have all the other domains set up then we can enforce the
scratch domain -> scratch ID restriction.

I thought where we heading was only the resource types would have ComputeKey
methods and then specialized domains had to pass their customizing parameters
into the resource's ComputeKey methods.

http://codereview.appspot.com/6448143/diff/2001/include/gpu/GrTypes.h#newcode523
include/gpu/GrTypes.h:523: // of these, you should definitely have a key
On 2012/08/13 13:48:24, bsalomon wrote:
> (or use the scratch key). ?

Done.

[bsalomon, 2012-08-13 15:33:08]

LGTM

On 2012/08/13 14:14:51, robertphillips wrote:
> http://codereview.appspot.com/6448143/diff/2001/include/gpu/GrTypes.h
> File include/gpu/GrTypes.h (right):
> 
>
http://codereview.appspot.com/6448143/diff/2001/include/gpu/GrTypes.h#newcode516
> include/gpu/GrTypes.h:516: * All scratch resources should be Unrestricted so
> they can be used
> Done - I don't think we will want individual domains hoarding scratch
textures.
> Short term we will need to allow non-scratch ID's to co-exist with the scratch
> domain. Once we have all the other domains set up then we can enforce the
> scratch domain -> scratch ID restriction.
> 
> I thought where we heading was only the resource types would have ComputeKey
> methods and then specialized domains had to pass their customizing parameters
> into the resource's ComputeKey methods.

I suppose I meant "public-id-generation" not "key-generation". I didn't mean to
say that each domain would have its own ComputeKey logic, just a way of
determining a unique public id within the domain without interference from other
domains or the scratch domain.


> 
>
http://codereview.appspot.com/6448143/diff/2001/include/gpu/GrTypes.h#newcode523
> include/gpu/GrTypes.h:523: // of these, you should definitely have a key
> On 2012/08/13 13:48:24, bsalomon wrote:
> > (or use the scratch key). ?
> 
> Done.

[robertphillips, 2012-08-13 17:48:21]

committed as r5065