Re: [PATCH 5/9] drm/i915: Fix Yf tile width

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 04, 2017 at 08:42:28PM +0200, ville.syrjala@xxxxxxxxxxxxxxx wrote:
> From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> 
> 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@xxxxxxxxxxxxxxx>

Reviewed-by: Imre Deak <imre.deak@xxxxxxxxx>

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@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux