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

[Neil Roberts]

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.

> +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?

Regards,
- Neil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150310/253e0ab9/attachment.sig>