[Glamor] [PATCH 06/15] glamor-fbo-pool: Implement fbo cache mechanism.

Chris Wilson chris at chris-wilson.co.uk
Fri Jan 20 04:51:59 PST 2012


On Fri, 20 Jan 2012 16:52:04 +0800, zhigang.gong at linux.intel.com wrote:
> From: Zhigang Gong <zhigang.gong at linux.intel.com>
> 
> We classify the cache according to the texture's format/width/height.
> As openGL doesn't allow us to change a texture's format/width/height
> after the internal texture object is already allocated, we can't
> just calculate the size and then according ths size to put the
> fbo to an bucket which is just like SNA does. We can only put
> the fbo to the corresponding format/width/height bucket.
> 
> +inline static int cache_wbucket(int size)
> +{
> +	int order = ffs(size / 256);	
> +	if (order > CACHE_BUCKET_WCOUNT)
> +		order = CACHE_BUCKET_WCOUNT; 
> +	return order;
> +}
> +
> +inline static int cache_hbucket(int size)
> +{
> +	int order = ffs(size / 256);	
> +	if (order > CACHE_BUCKET_HCOUNT)
> +		order = CACHE_BUCKET_HCOUNT; 
> +	return order;
> +}

These do need to be "find last bit" so that each bucket only contains
sizes within a power of two band. So that your later use of the buckets
to find a containing size are more likely to succeed with fewer misses.
(Unless I've overlooked that you only ever create power-of-two
textures.)

However, I'm not entirely convinced that this is not just working around
a bad driver that has poor texture/fbo allocation?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Glamor mailing list