[Intel-gfx] [PATCH 5/9] drm/i915: Fix Yf tile width

Imre Deak imre.deak at intel.com
Thu Feb 2 15:07:47 UTC 2017


On Wed, Jan 04, 2017 at 08:42:28PM +0200, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> 
> Based on empirical evidence the display engine (at least) always
> treats Yf tiles as 128Bx32. Currently we're assuming the tile dimensions
> change based on the pixel format. Let's adjust our code to match the
> hardware.
> 
> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>

Reviewed-by: Imre Deak <imre.deak at intel.com>

BSpec "Address Tiling Function Introduction/Linear vs Tiled Storage":
"""
Note that the dimensions of tiles are irrespective of the data contained
within – e.g., a tile can hold twice as many 16-bit pixels (256
pixels/row x 8 rows = 2K pixels) than 32-bit pixels (128 pixels/row x 8
rows = 1K pixels).
"""

"Tile-Yf Format":
"""
The 64 Byte block is always 4-high. Width (in pixels) is defined by bpp.
"""

Then it continues to specify the different tile aspect ratios for
different bpps which contradict the above. This aspect ratio definition
is what matches the current code. Filing a BSpec issue for this would be
good.

> ---
>  drivers/gpu/drm/i915/intel_display.c | 20 ++++++--------------
>  1 file changed, 6 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index bc398743e941..0ca0dbccc005 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2070,20 +2070,12 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, int plane)
>  		else
>  			return 512;
>  	case I915_FORMAT_MOD_Yf_TILED:
> -		switch (cpp) {
> -		case 1:
> -			return 64;
> -		case 2:
> -		case 4:
> -			return 128;
> -		case 8:
> -		case 16:
> -			return 256;
> -		default:
> -			MISSING_CASE(cpp);
> -			return cpp;
> -		}
> -		break;
> +		/*
> +		 * Bspec seems to suggest that the Yf tile width would
> +		 * depend on the cpp. In reality it doesn't, at least
> +		 * as far as the display engine is concerned.
> +		 */
> +		return 128;
>  	default:
>  		MISSING_CASE(fb->modifier);
>  		return cpp;
> -- 
> 2.10.2
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


More information about the Intel-gfx mailing list