<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Op 27-03-17 om 17:52 schreef Mahesh
Kumar:<br>
</div>
<blockquote
cite="mid:330de826-0253-50c2-11f4-cd45b7d31d8d@intel.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
<b>Arbitrated system bandwidth workarounds for watermark.</b><br>
<br>
All GEN-9 based platforms require watermark related WA to be
enabled if Display memory bandwidth requirement is exceeding XX%
of total available system memory bandwidth.<br>
This XX% depend on multiple factors.<br>
<b>e.g.</b> if all the enabled planes have X-tiled or linear
memory then,<br>
XX = 60<br>
if any Y-tiled plane is enabled then<br>
XX = 20 etc.<br>
In current implementation of workarounds we enable maximum WA
(i.e. add 15us latency during WM calculation) irrespective of
workaround is required OR not. <br>
total display bandwidth requirement is sum of display requirement
of individual pipe, In order to calculate correct BW requirement
plane configuration of any pipe should not be changing during
calculation.<br>
<br>
To implement & optimize above requirement many implementations
are possible, I'm proposing few of options.<br>
Please review & let know which option is better to implement
WA's.<br>
<br>
<b>Option 1:</b><br>
<blockquote>Use connection_mutex (this will change to i915
specific lock only that is available in atomic design) to
serialize all the commits.<br>
If memory bandwidth WA is changing then get all crtc_states for
calculating watermark values.<br>
<b>Pros:</b><br>
<ul>
<li>In each flip optimum WM values (not more than the required
value) will be used.</li>
</ul>
<b>Cons:</b><br>
<ul>
<li>This approach will serialize all the flips so there will
be performance impact, in case of blocking commits this
impact will be even worse, e.g. three display with
refresh-rate of 30fps, 60fps & 90fps.</li>
<li>If commit is going-on in 30FPS display, all other flip
will be blocked & frames in 60 & 90fps display will
be dropped/blocked.</li>
</ul>
</blockquote>
<b> Option 2:</b><br>
<blockquote>Use two levels of system bandwidth check, once during
calculation & second during commit.<br>
During intel_atomic_check (as part of compute_ddb) dont hold
any system level mutex, instead hold WM mutex & compute
system bandwidth requirement. If WA is changing then get
crtc_state of all other pipes & go ahead with commit.<br>
During intel_atomic_commit, again take wm_mutex &
recalculate complete system bandwidth requirement. If
requirement is changed in a way that computed WM are not valid
anymore fail the flip.<br>
Update the bandwidth requirement for each plane in global state
(dev_priv->wm) so other flips dont need to recalculate it.<br>
<br>
<b>Pros:</b><br>
<ul>
<li>It reduces critical section time.</li>
<li>Still optimum use of available DDB & optimum WM values
are used.</li>
</ul>
<b>Cons:</b><br>
<ul>
<li>If memory bandwidth WA are changing very frequently then
there will be many flip failures which will impact the
performance.</li>
</ul>
<br>
</blockquote>
<b>Option 3:</b><br>
<blockquote>Compute maximum bandwidth requirement during modeset.<br>
i.e. if modeset is of 1080p @60fps & maximum plane in CRTC
are 3, with maximum supported downscale amount XX.YY (defined
by min of cdclk/crtc_clock & max(hscale x vscale)) then max
bandwidth requirement for CRTC will be<br>
(1080p x 60 x 3 x XX.YY).<br>
<br>
Now during flip if there is any change which will change the WA
(e.g. tiling change) then take wm_mutex lock & recalculate
complete bandwidth requirement. If WA is changing then get
crtc_state of all other pipes & go ahead with commit. (if
total display memory BW % is less than lowest % to enable WA
i.e. 20%, then no need to recompute)<br>
Update per-CRTC bandwidth requirement in global state so other
flips dont need to recalculate each time.<br>
<br>
<b>Pros:</b><br>
<ul>
<li>All CRTC can flip independently until there is change
which will impact WA.</li>
<li>No locking until potential WM WA change.</li>
</ul>
<b>Cons:</b><br>
<ul>
<li>If memory bandwidth WA is changing very frequently then
there will be slight performance impact.</li>
<li>We may not be programming optimum WM values, which may
have some power impact.</li>
</ul>
<p><br>
</p>
</blockquote>
<p>If you think any other approach should be used please let know
that as well.<br>
</p>
<br>
</blockquote>
<pre>Option 4:
Check if watermarks for the current pipe needs global adjustment between last commit and current, if not do nothing.
If there is, we could do 1 of the below:
1. Blindly grab all other crtc state and do watermark reprogramming.
2. If it does need adjustment, grab all other crtc's mutexes and see if we need to adjust watermark state. If we do, grab other affected crtc's states as well to perform watermark reprogramming.
Perhaps add some elements of option 3 too? I like that one too.
~Maarten
</pre>
</body>
</html>