[Mesa-dev] [PATCH] intel: Be more conservative in disabling tiling to save memory.

[Kenneth Graunke]

On 04/29/2013 10:24 AM, Eric Anholt wrote:
> Daniel Vetter <daniel at ffwll.ch> writes:
>
>> On Thu, Apr 25, 2013 at 03:41:01PM -0700, Eric Anholt wrote:
>>> Improves GLB2.7 trex performance 1.01985% +/- 0.721366% on my IVB (n=10)
>>> and by 3.38771% +/- 0.584241% (n=15) on my HSW, due to a 32x32 ARGB8888
>>> cubemap going from untiled to tiled.
>>> ---
>>>   src/mesa/drivers/dri/intel/intel_mipmap_tree.c |    8 +++++---
>>>   1 file changed, 5 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
>>> index 98f1e98..12a4a22 100644
>>> --- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
>>> +++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
>>> @@ -345,11 +345,13 @@ intel_miptree_choose_tiling(struct intel_context *intel,
>>>           base_format == GL_DEPTH_STENCIL_EXT))
>>>         return I915_TILING_Y;
>>>
>>> -   /* If the width is smaller than a tile, don't bother tiling. */
>>> -   if (width0 < 64)
>>> +   int minimum_pitch = mt->total_width * mt->cpp;
>>> +
>>> +   /* If the width is much smaller than a tile, don't bother tiling. */
>>> +   if (minimum_pitch < 64)
>>>         return I915_TILING_NONE;
>>
>> The old limit made sense for X-tiled and dword-size pixels, so shouldn't
>> we move this around a bit and keep a break of 256b for X-tiled and 64b
>> when Y-tiling is possible?
>>
>> Otoh only pre-gen6 would care, so meh. Either way
>>
>> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>
> We need to get to Y-tiled on pre-gen6 anyway.
>
> I'm tempted to remove this fallback code entirely.  The cost of going
> untiled is just too large -- in this patch I'm optimizing a 32x32
> cubemap (a page per face) that's very infrequently used by the
> application, and still seeing this benefit.  I think we'd be serving
> users better to just always allocate tiled -- the original cause of it
> was only about a 2x memory savings for a badly-written app (estimate:
> allocating 1MB instead of 2MB for what was only 128kb of actual texture
> data).

That makes sense to me.  Textures with such tiny base levels ought to be 
really uncommon in real applications (as opposed to piglit tests), so I 
doubt there would be much memory savings.  If a 32x32 cubemap shows an 
improvement, that indicates just allocating it tiled is a good idea.

--Ken