[Mesa-dev] [PATCH 6/6] i965: Allow Y-tiled allocations for large surfaces

[Ben Widawsky]

On Tue, Mar 10, 2015 at 05:39:24PM +0000, Neil Roberts wrote:
> Ben Widawsky <benjamin.widawsky at intel.com> writes:
> 
> > This patch will use a new calculation to determine if a surface can be blitted
> > from or to. Previously, the "total_height" member was used. Total_height in the
> > case of 2d, 3d, and cube map arrays is the height of each slice/layer/face.
> > Since the GL map APIS only ever deal with a slice at a time however, the
> > determining factor is really the height of one slice.
> 
> Do you mean to say that total_height is the combined height of all of
> the slices/layers/faces? If so the wording is confusing.
> 

Yep. Thanks, I agree, and fixed.

> > +static inline uint32_t
> > +intel_miptree_blit_height(struct intel_mipmap_tree *mt)
> > +{
> > +   switch (mt->target) {
> > +   case GL_TEXTURE_CUBE_MAP:
> > +   case GL_TEXTURE_1D_ARRAY:
> > +   case GL_TEXTURE_2D_ARRAY:
> > +   case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
> > +   case GL_TEXTURE_CUBE_MAP_ARRAY:
> > +      assert(mt->logical_depth0);
> > +      return mt->qpitch;
> > +   case GL_TEXTURE_3D:
> > +      /* FIXME 3d textures don't have a qpitch. I think it's simply the tiled
> > +       * aligned mt->physical_height0. Since 3D textures aren't used often, just
> > +       * print the perf debug from the caller and bail
> > +       */
> > +      /* fallthrough */
> > +   default:
> > +      return mt->total_height;
> > +   }
> > +}
> 
> This function might stop working on Skylake if we land my patch to fix
> the qpitch calculation. In that case the qpitch isn't necessarily a
> count of the number of rows. In 1D textures it is the number of pixels
> and for compressed textures it is the number of blocks. Maybe we could
> also store the physical_qpitch that is calculated in
> brw_miptree_layout_texture_array?
> 

I'm pretty sure today we never use the blitter for compressed textures.
Therefore, I believe we can ignore that case. In the case where we use pixels, I
believe it will still work fine as long as long as each layer is tightly packed
(which I thought it was). If it's not, then I suppose we have a problem. I'm
also totally fine with making 1D fallthrough since I don't think it's a
particularly common case for it to surpass total_height anyway.

Any preference on which to land first (and therefore who has to fix it)? My
patches are older, but yours potentially fixes bugs and mine is just perf.

> Regards,
> - Neil



-- 
Ben Widawsky, Intel Open Source Technology Center