Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1453157

Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks

Show all headers | View raw

On Mon, Aug 01, 2016 at 10:48:37AM +0200, Maarten Lankhorst wrote:
> Op 29-07-16 om 22:33 schreef Matt Roper:
> > On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote:
> >> On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote:
> >>> This is completely untested (and probably horribly broken/buggy), but
> >>> here's a quick mockup of the general approach I was thinking for
> >>> ensuring DDB & WM's can be updated together while ensuring the
> >>> three-step pipe flushing process is honored:
> >>>
> >>>         https://github.com/mattrope/kernel/commits/experimental/lyude_ddb
> >>>
> >>> Basically the idea is to take note of what's happening to the pipe's DDB
> >>> allocation (shrinking, growing, unchanged, etc.) during the atomic check
> >>> phase;
> >> Didn't look too closely, but I think you can't actually do that unless
> >> you lock all the crtcs whenever the number of active pipes is goind to
> >> change. Meaning we'd essentially be back to the one-big-modeset-lock
> >> apporach, which will cause missed flips and whanot on the other pipes.
> >>
> >> The alternative I think would consist of:
> >> - make sure level 0 watermark never exceeds total_ddb_size/max_pipes,
> >>   so that a modeset doesn't have to care about the wms for the other
> >>   pipes not fitting in
> > Unfortunately this part is the problem.  You might get away with doing
> > this on SKL/KBL which only have three planes max per pipe and a large
> > (896 block) DDB, but on BXT you have up to four planes (we don't
> > actually enable the topmost plane in a full-featured manner just yet,
> > but need to soon), yet the total DDB is only 512 blocks.  Sadly, the
> > platform with more planes was given a smaller DDB...   :-(
> > We're already in trouble because users that are running setups like 3x
> > 4K with most/all planes in use at large sizes can't find level 0
> > watermarks that satisfy their needs and we have to reject the whole
> > configuration.  If we further limit each pipe's usage to total/maxpipes
> > (i.e., 170 blocks per pipe on BXT), then we're going to hit similar
> > issues when only driving one or two displays with with all of the planes
> > in use, even though we should have had more DDB space to work with.
> >
> > I guess serious plane usage isn't too common in desktop setups today,
> > but it's a very critical feature in the embedded world; we can't really
> > afford to cripple plane usage further.  Unfortunately, as you point out
> > above, this means that we have to follow the bspec's DDB allocation
> > method, which in turn means we need to grab _all_ CRTC locks any time
> > _any_ CRTC is being turned on or turned off which is a BKL-style way of
> > doing things.
> Meh, I'm running into a similar issue on vlv/chv. I don't see a way around it. :(

Now are you hitting it w/ vlv/chv? They don't even have a shared DDB.

> Only thing we could do is split up the state to make the non-modeset
> crtc's complete early.

-- 
Ville Syrjälä
Intel OTC

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH v4 0/6] Finally fix watermarks Lyude <cpaul@redhat.com> - 2016-07-26 19:40 +0200
  [PATCH v4 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs Lyude <cpaul@redhat.com> - 2016-07-26 19:40 +0200
    Re: [PATCH v4 1/6] drm/i915/skl: Add support for the SAGV, fix  underrun hangs Matt Roper <matthew.d.roper@intel.com> - 2016-07-28 15:20 +0200
    Re: [v4,1/6] drm/i915/skl: Add support for the SAGV, fix underrun  hangs Hans de Goede <hdegoede@redhat.com> - 2016-08-02 18:30 +0200
  Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks Matt Roper <matthew.d.roper@intel.com> - 2016-07-29 02:10 +0200
    Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks Ville Syrjälä <ville.syrjala@linux.intel.com> - 2016-07-29 11:40 +0200
      Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks Lyude <cpaul@redhat.com> - 2016-07-29 20:50 +0200
        Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks Ville Syrjälä <ville.syrjala@linux.intel.com> - 2016-07-29 21:30 +0200
          Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks Lyude <cpaul@redhat.com> - 2016-07-29 21:50 +0200
          Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks Matt Roper <matthew.d.roper@intel.com> - 2016-07-29 22:50 +0200
            Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks Ville Syrjälä <ville.syrjala@linux.intel.com> - 2016-08-01 14:00 +0200
      Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks Matt Roper <matthew.d.roper@intel.com> - 2016-07-29 22:40 +0200
        Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks Maarten Lankhorst <maarten.lankhorst@linux.intel.com> - 2016-08-01 11:00 +0200
          Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks Ville Syrjälä <ville.syrjala@linux.intel.com> - 2016-08-01 13:50 +0200
            Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks Maarten Lankhorst <maarten.lankhorst@linux.intel.com> - 2016-08-02 18:00 +0200
              Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks Ville Syrjälä <ville.syrjala@linux.intel.com> - 2016-08-02 18:10 +0200

csiph-web