[Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12
Maarten Lankhorst
maarten.lankhorst at linux.intel.com
Thu Apr 19 11:30:32 UTC 2018
Op 19-04-18 om 13:22 schreef Ville Syrjälä:
> On Thu, Apr 19, 2018 at 02:36:42AM +0000, Srinivas, Vidya wrote:
>>
>>
>>
>>> -----Original Message-----
>>> From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
>>> Sent: Thursday, April 19, 2018 12:06 AM
>>> To: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
>>> Cc: Srinivas, Vidya <vidya.srinivas at intel.com>; intel-
>>> gfx at lists.freedesktop.org
>>> Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add
>>> skl_check_nv12_surface for NV12
>>> On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:
>>>> Op 18-04-18 om 17:32 schreef Ville Syrjälä:
>>>>> On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
>>>>>> From: Maarten Lankhorst <maarten.lankhorst at linux.intel.com<mailto:maarten.lankhorst at linux.intel.com>>
>>>>>> We skip src trunction/adjustments for
>>>>>> NV12 case and handle the sizes directly.
>>>>>> Without this, pipe fifo underruns are seen on APL/KBL.
>>>>>> v2: For NV12, making the src coordinates multiplier of 4
>>>>>> v3: Moving all the src coords handling code for NV12 to
>>>>>> skl_check_nv12_surface
>>>>>> Signed-off-by: Maarten Lankhorst
>>>>>> <maarten.lankhorst at linux.intel.com<mailto:maarten.lankhorst at linux.intel.com>>
>>>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas at intel.com<mailto:vidya.srinivas at intel.com>>
>>>>>> ---
>>>>>> drivers/gpu/drm/i915/intel_display.c | 39
>>>>>> ++++++++++++++++++++++++++++++++++++
>>>>>> drivers/gpu/drm/i915/intel_sprite.c | 15 ++++++++++----
>>>>>> 2 files changed, 50 insertions(+), 4 deletions(-)
>>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>>>>> b/drivers/gpu/drm/i915/intel_display.c
>>>>>> index 925402e..b8dbaca 100644
>>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>>>>> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const
>>> struct intel_crtc_state *crtc_state,
>>>>>> return 0;
>>>>>> }
>>>>>> +static int
>>>>>> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
>>>>>> + struct intel_plane_state *plane_state) {
>>>>>> + int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
>>>>>> + int crtc_y2 = plane_state->base.crtc_y +
>>>>>> +plane_state->base.crtc_h;
>>>>>> +
>>>>>> + if (((plane_state->base.src_x >> 16) % 4) != 0 ||
>>>>>> + ((plane_state->base.src_y >> 16) % 4) != 0 ||
>>>>>> + ((plane_state->base.src_w >> 16) % 4) != 0 ||
>>>>>> + ((plane_state->base.src_h >> 16) % 4) != 0) {
>>>>>> + DRM_DEBUG_KMS("src coords must be multiple of 4 for
>>> NV12\n");
>>>>>> + return -EINVAL;
>>>>>> + }
>>>>> I don't really see why we should check these. The clipped
>>>>> coordinates are what matters.
>>>> To propagate our limits to the userspace. I think we should do it for
>>>> all formats, but NV12 is the first YUV format we have tests for. If we
>>>> could we should do something similar for the other YUV formats, but they
>>> have different requirements.
>>>> In case of NV12 we don't have existing userspace, there will be
>>>> nothing that breaks if we enforce limits from the start.
>>> But what about sub-pixel coordinates? You're totally ignoring them here.
>>> We need to come up with some proper rules for this stuff.
>>>>>> +
>>>>>> + /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
>>>>>> + if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w %
>>> 4) ||
>>>>>> + (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4))
>>> {
>>>>>> + DRM_DEBUG_KMS("It's not possible to clip %u,%u to
>>> %u,%u\n",
>>>>>> + crtc_x2, crtc_y2,
>>>>>> + crtc_state->pipe_src_w, crtc_state->pipe_src_h);
>>>>>> + return -EINVAL;
>>>>>> + }
>>>>> Why should we care? The current code already plays it fast and loose
>>>>> and allows the dst rectangle to shrink to accomodate the hw limits.
>>>>> If we want to change that we should change it universally.
>>>> Unfortunately for the other formats we already have an existing
>>>> userspace
>>>> (X.org) that doesn't perform any validation. We can't change it for
>>>> that, but we can prevent future mistakes.
>>> We should do it uniformly. Not per-format. That will make the code
>>> unmaintainable real quick.
>>>>>> +
>>>>>> + plane_state->base.src.x1 =
>>>>>> + DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) <<
>>> 18;
>>>>>> + plane_state->base.src.x2 =
>>>>>> + DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) <<
>>> 18;
>>>>>> + plane_state->base.src.y1 =
>>>>>> + DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) <<
>>> 18;
>>>>>> + plane_state->base.src.y2 =
>>>>>> + DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) <<
>>> 18;
>>>>> Since this can now increase the size of the source rectangle our
>>>>> scaling factor checks are no longer 100% valid. We might end up with
>>>>> a scaling factor that is too high.
>>>>> I don't really like any of these "let's make NV12 behave special"
>>>>> tricks. We should make the code behave the same way for all pixel
>>>>> formats instead of adding format specific hacks.
>>>> This is not nivalid because we restrict the original src coordinates
>>>> to be a multiple of 4, you can only clip to something smaller, not to
>>>> something bigger. :)
>>> The clipped coordinates can be whatever thanks to scaling/etc.
>>> Also why are we trying to make everything a multiple of four? I don't
>>> remember any hw restrictions like that.
>>
>>
>> Hi
>>
>>
>> As per WA1106, Display corruption/color shift observed when using NV12 with 270 rotation or 90 rotation + horizontal flip.
>>
>> WA: NV12 with 270 rotation or 90 rotation + horizontal flip requires the programmed plane height to be a multiple of 4.
> Does plane height here mean src height or dst height?
>
> Either way I don't see why we aren't just checking for the right thing
> instead of trying to mandate a four pixel alignment everywhere.
>
Agreed, what about the below diff, would this be acceptable to you? I deliberately ignore the last 16 bits as that is what we currently do anyway for all formats.
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 4b3735720fee..3ff7b5491446 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3090,6 +3090,31 @@ static int skl_check_main_surface(const struct intel_crtc_state *crtc_state,
return 0;
}
+static int
+skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
+ struct intel_plane_state *plane_state)
+{
+ /* Display WA #1106 */
+ if (plane_state->base.rotation != (DRM_MODE_REFLECT_X | DRM_MODE_ROTATE_90) &&
+ plane_state->base.rotation != DRM_MODE_ROTATE_270)
+ return 0;
+
+ /* Because x/y are src coordinates will be rotated, we look at x/width here. */
+ if (((plane_state->base.src_x >> 16) % 4) != 0 ||
+ ((plane_state->base.src_w >> 16) % 4) != 0) {
+ DRM_DEBUG_KMS("src x/w must be multiple of 4 for rotated NV12\n");
+ return -EINVAL;
+ }
+
+ /* And round y here */
+ plane_state->base.src.y1 =
+ DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
+ plane_state->base.src.y2 =
+ DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18;
+
+ return 0;
+}
+
static int skl_check_nv12_aux_surface(struct intel_plane_state *plane_state)
{
const struct drm_framebuffer *fb = plane_state->base.fb;
@@ -3173,6 +3198,9 @@ int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
* the main surface setup depends on it.
*/
if (fb->format->format == DRM_FORMAT_NV12) {
+ ret = skl_check_nv12_surface(crtc_state, plane_state);
+ if (ret)
+ return ret;
ret = skl_check_nv12_aux_surface(plane_state);
if (ret)
return ret;
More information about the Intel-gfx
mailing list