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

[Chris Wilson]

Quoting Ville Syrjälä (2018-09-20 20:41:30)
> On Thu, Sep 20, 2018 at 09:09:03AM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2018-09-19 17:59:51)
> > > 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.
> > 
> > At which point, the client can just ignore this field and just use
> > rejection criteria from addfb2 and/or setcrtc (or the atomic variant).
> 
> I suppose. Though probing the max size using addfb might be a bit
> tedious. That's assuming the client wants to report the max in some
> way, as X does.
> 
> > 
> > Or we can just keep this field as meaning the maximum size of a single
> > CRTC and just ignore it entirely in -modesetting for fb size as we do
> > elsewhere.
> 
> Would require changing the core addfb code to ignore these
> limits for i915 but keep chekcing them for the other drivers.
> So a bit of work, and I'm not really sure what the actual
> benefit for i915 would be.

Why is the core addfb using these fields? Since when did they *stop*
being per-CRTC limits?
-Chris