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