[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 14:19:54 UTC 2018
Op 19-04-18 om 13:50 schreef Ville Syrjälä:
> On Thu, Apr 19, 2018 at 01:30:32PM +0200, Maarten Lankhorst wrote:
>> 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;
> Hmm. I wonder if that's what the spec actually means. The HSDs only
> talk about 270 degree rotation. So I guess this interpretation could
> be correct.
>
>> +
>> + /* 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;
> Why not just a simple
>
> if (drm_rect_height(src) >> 16 % 4 != 0)
> return -EINVAL;
>
So lets do that, but we have to fix the rounding errors in i915 to make it useful:
upscaling 16x16 to 2560x1440:
(kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "SRC_W" to 0x100000/1048576
(kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "SRC_H" to 0x100000/1048576
(kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "CRTC_X" to 0x0/0
(kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "CRTC_Y" to 0x0/0
(kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "CRTC_W" to 0xa00/2560
(kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "CRTC_H" to 0x5a0/1440
[ 290.766555] [drm:drm_ioctl [drm]] pid=1172, dev=0xe200, auth=1, DRM_IOCTL_MODE_ATOMIC
...
[ 290.767276] [drm:skl_update_scaler [i915]] NV12: src dimensions not met: 15 < 16
[ 290.767284] [drm:drm_atomic_helper_check_planes [drm_kms_helper]] [PLANE:33:plane 2A] atomic driver check failed
[ 290.767422] [drm:drm_ioctl [drm]] pid=1172, ret = -22
If we want to go with that patch, I'll commit it but let the tests fail since rounding is not a NV12 specific error.
~Maarten
More information about the Intel-gfx
mailing list