On Mon, May 08, 2017 at 05:18:51PM +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. > > 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 Given the dbuf size of 508, I assume this example is for Broxton hardware, right? In that case, you wouldn't actually be able to use the cursor plane since Plane 4 (1440x96) is mutually exclusive with the cursor, so there wouldn't be a need to reserve these 32 blocks. I guess there's also the issue that the upstream driver can't actually expose/use Plane 4 at all today. That said, your overall example here still gets the important points across and is very much appreciated. > 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 It's probably worth noting that the use cases that are most likely to benefit from this are those with large differences in the height of the 'shortest' plane vs the height of the 'tallest' plane. It's the blind proportional distribution of remaining blocks in the current algorithm that prevents 'short' planes from reaching their minimum block requirements for various watermark levels (and if they can't even reach the WM0 minimum, then the plane can't be used at all). There will certainly still be cases where the overall display configuration (with lots of pipes and planes in use) simply requires more blocks than the hardware has to even reach WM0, no matter how we slice up the limited DDB size, but the changes here will definitely help prevent us from rejecting atomic commits for some configurations we actually could handle. Matt > > Mahesh Kumar (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 > > 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 | 520 +++++++++++++++++++++++------------ > 4 files changed, 395 insertions(+), 186 deletions(-) > > -- > 2.11.0 > -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
