Re: [PATCH 00/12] Implement DDB algorithm and WM cleanup

[Matt Roper <matthew.d.roper@intel.com>]

On Wed, May 17, 2017 at 05:28:19PM +0530, Mahesh Kumar wrote:
> This series implements new DDB allocation algorithm to solve the cases,
> where we have sufficient DDB available to enable multiple planes, But
> due to the current algorithm not dividing it properly among planes, we
> end-up failing the flip.
> It also takes care of enabling same watermark level for each
> plane, for efficient power saving.
> Series also fixes/cleans-up few bug in present code.

The whole series has a r-b from Maarten and all but #11 has a r-b from
me (and a couple of the patches also have a third r-b too).  There's at
least one minor typo in #11 and one other item I'd like clarification on
before merging (I'm probably just overlooking something, but I want to
make sure), but the first 10 patches here are definitely ready to go
(and have a clean CI result), so I've gone ahead and merged them to
dinq.  We can probably get the last two patches in tomorrow unless
something completely blows up.

Thanks for your hard work on this!


Matt

> 
> There are two steps in current WM programming.
> 
> 1. Calculate minimum number of blocks required  for a WM level to be
> enabled. For 1440x2560 panel we need 41 blocks as minimum number of
> blocks to enable WM0. This is the step which doesn't use vertical size.
> It only depends on Pipe drain rate and plane horizontal size as per the
> current Bspec algorithm.
> So all the plane below have minimum  number of blocks required to enable
> WM0 as 41
>     Plane 1  - 1440x2560        -    Min blocks to enable WM0 = 41
>     Plane 2  - 1440x2560        -    Min blocks to enable WM0 = 41
>     Plane 3  - 1440x48          -    Min blocks to enable WM0 = 41
>     Plane 4  - 1440x96          -    Min blocks to enable WM0 = 41
> 
> 2. Number of blocks allotted by the driver
>     Driver allocates  12 for Plane 3   &  16 for plane 4
> 
>     Total Dbuf Available = 508
>     Dbuf Available after 32 blocks for cursor = 508 - (32)  = 476
>     allocate minimum blocks for each plane 8 * 4 = 32
>     remaining blocks = 476 - 32 = 444
>     Relative Data Rate for Planes
>        Plane 1  =  1440 * 2560 * 3  =  11059200
>        Plane 2  =  1440 * 2560 * 3  =  11059200
>        Plane 3  =  1440 * 48   * 3  =  207360
>        Plane 4  =  1440 * 96   * 3  =  414720
>        Total Relative BW            =  22740480
> 
> -   Allocate Buffer
>     buffer allocation = (Plane relative data rate / total data rate)
> 		    * total remaming DDB + minimum plane DDB
>      Plane 1  buffer allocation = (11059200 / 22740480) * 444 + 8 = 223
>      Plane 2  buffer allocation = (11059200 / 22740480) * 444 + 8 = 223
>      Plane 3  buffer allocation = (207360   / 22740480) * 444 + 8 = 12
>      Plane 4  buffer allocation = (414720   / 22740480) * 444 + 8 = 16
> 
> In this case it forced driver to disable Plane 3 & 4. Driver need to use
> more efficient way to allocate buffer that is optimum for power.
> 
> New Algorithm suggested by HW team is:
> 
> 1. Calculate minimum buffer allocations for each plane and for each
>     watermark level
> 
> 2. Add minimum buffer allocations required for enabling WM7
>     for all the planes
> 
> Level 0 =  41 + 41 + 41 + 41  = 164
> Level 1 =  42 + 42 + 42 + 42  = 168
> Level 2 =  42 + 42 + 42 + 42  = 168
> Level 3 =  94 + 94 + 94 + 94 =  376
> Level 4 =  94 + 94 + 94 + 94 =  376
> Level 5 =  94 + 94 + 94 + 94 =  376
> Level 6 =  94 + 94 + 94 + 94 =  376
> Level 7 =  94 + 94 + 94 + 94 =  376
> 
> 3. Check to see how many buffer allocation are left and enable
> the best case. In this case since we have 476 blocks we can enable
> WM0-7 on all 4 planes.
> Let's say if we have only 200 block available then the best cases
> allocation is to enable Level2 which requires 168 blocks
> 
> Kumar, Mahesh (11):
>   drm/i915: fix naming of fixed_16_16 wrapper.
>   drm/i915: Add more wrapper for fixed_point_16_16 operations
>   drm/i915: Use fixed_16_16 wrapper for division operation
>   drm/i915/skl+: calculate pixel_rate & relative_data_rate in fixed
>     point
>   drm/i915/skl: Fail the flip if no FB for WM calculation
>   drm/i915/skl+: no need to memset again
>   drm/i915/skl+: Fail the flip if ddb min requirement exceeds pipe
>     allocation
>   drm/i915/skl+: Watermark calculation cleanup
>   drm/i915/skl+: use linetime latency if ddb size is not available
>   drm/i915/skl: New ddb allocation algorithm
>   drm/i915/skl+: consider max supported plane pixel rate while scaling
> 
> Kumar, Mahesh (12):
>   drm/i915: fix naming of fixed_16_16 wrapper.
>   drm/i915: Add more wrapper for fixed_point_16_16 operations
>   drm/i915: Use fixed_16_16 wrapper for division operation
>   drm/i915/skl+: calculate pixel_rate & relative_data_rate in fixed
>     point
>   drm/i915/skl: Fail the flip if no FB for WM calculation
>   drm/i915/skl+: no need to memset again
>   drm/i915/skl+: Fail the flip if ddb min requirement exceeds pipe
>     allocation
>   drm/i915/skl+: Watermark calculation cleanup
>   drm/i915/skl+: Perform wm level calculations in separate function
>   drm/i915/skl+: use linetime latency if ddb size is not available
>   drm/i915/skl: New ddb allocation algorithm
>   drm/i915/skl+: consider max supported plane pixel rate while scaling
> 
>  drivers/gpu/drm/i915/i915_drv.h      |  56 +++-
>  drivers/gpu/drm/i915/intel_display.c |   3 +
>  drivers/gpu/drm/i915/intel_drv.h     |   2 +
>  drivers/gpu/drm/i915/intel_pm.c      | 527 +++++++++++++++++++++++------------
>  4 files changed, 400 insertions(+), 188 deletions(-)
> 
> -- 
> 2.11.0
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx