From: Mahesh Kumar <mahesh1.kumar@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: paulo.r.zanoni@intel.com, maarten.lankhorst@intel.com
Subject: [PATCH 0/8] Implement DDB algorithm and WM cleanup
Date: Tue, 28 Feb 2017 17:01:35 +0530 [thread overview]
Message-ID: <20170228113143.8280-1-mahesh1.kumar@intel.com> (raw)
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.
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
Mahesh Kumar (8):
drm/i915/skl+: calculate pixel_rate & relative_data_rate in fixed
point
drm/i915/skl+: use linetime latency if ddb size is not available
drm/i915/skl: Fail the flip if no FB for WM calculation
drm/i915/skl+: no need to memset again
drm/i915/skl+: ddb min requirement may exceed allocation
drm/i915/skl+: Watermark calculation cleanup
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 | 52 +++-
drivers/gpu/drm/i915/intel_display.c | 3 +
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_pm.c | 511 +++++++++++++++++++++++------------
4 files changed, 384 insertions(+), 184 deletions(-)
--
2.11.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next reply other threads:[~2017-02-28 11:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-28 11:31 Mahesh Kumar [this message]
2017-02-28 11:31 ` [PATCH 1/8] drm/i915/skl+: calculate pixel_rate & relative_data_rate in fixed point Mahesh Kumar
2017-03-16 18:48 ` Paulo Zanoni
2017-02-28 11:31 ` [PATCH 2/8] drm/i915/skl+: use linetime latency if ddb size is not available Mahesh Kumar
2017-02-28 11:31 ` [PATCH 3/8] drm/i915/skl: Fail the flip if no FB for WM calculation Mahesh Kumar
2017-02-28 11:31 ` [PATCH 4/8] drm/i915/skl+: no need to memset again Mahesh Kumar
2017-02-28 11:31 ` [PATCH 5/8] drm/i915/skl+: ddb min requirement may exceed allocation Mahesh Kumar
2017-04-12 9:17 ` Ander Conselvan De Oliveira
2017-04-12 15:09 ` Mahesh Kumar
2017-02-28 11:31 ` [PATCH 6/8] drm/i915/skl+: Watermark calculation cleanup Mahesh Kumar
2017-02-28 11:31 ` [PATCH 7/8] drm/i915/skl: New ddb allocation algorithm Mahesh Kumar
2017-02-28 11:31 ` [PATCH 8/8] drm/i915/skl+: consider max supported plane pixel rate while scaling Mahesh Kumar
2017-02-28 15:52 ` ✗ Fi.CI.BAT: failure for Implement DDB algorithm and WM cleanup Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170228113143.8280-1-mahesh1.kumar@intel.com \
--to=mahesh1.kumar@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=maarten.lankhorst@intel.com \
--cc=paulo.r.zanoni@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.