[Intel-gfx] [PATCH v2 5/5] drm/i915: Bump gen4+ fb size limits to 32kx32k

[Ville Syrjälä]

On Thu, Sep 13, 2018 at 11:01:40PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> 
> With gtt remapping in place we can use arbitraily large framebuffers.
> Let's bump the limits as high as we can (32k-1). Going beyond that
> would require switching our s16.16 src coordinate representation to
> something with more spare bits.
> 
> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 346572cf734a..0ee6255cd040 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15527,8 +15527,8 @@ int intel_modeset_init(struct drm_device *dev)
>  		dev->mode_config.max_width = 4096;
>  		dev->mode_config.max_height = 4096;
>  	} else {
> -		dev->mode_config.max_width = 8192;
> -		dev->mode_config.max_height = 8192;
> +		dev->mode_config.max_width = 32767;
> +		dev->mode_config.max_height = 32767;

It appears that neither Mesa nor glamor will check whether window system
buffers exceed the capabilities of the 3D engine. So trying to use a >16k
trips an assert when genxml tries to pack the surface_state.

So looks like we'll need to limit this to 16k for gen7+, and leave it
at 8k for gen4+. If userspace gets smarter later on we could add a new
client cap to expose higher limits.

If I'm reading the spec correctly gen4+ render engine has a stride
limit of 512KiB and gen7+ has 256KiB. So my choice of 256KiB seems
good enough for both.

>  	}
>  
>  	if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) {
> -- 
> 2.16.4

-- 
Ville Syrjälä
Intel