Message ID | 20231115131549.2191589-1-javierm@redhat.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b909:0:b0:403:3b70:6f57 with SMTP id t9csp2529000vqg; Wed, 15 Nov 2023 05:17:01 -0800 (PST) X-Google-Smtp-Source: AGHT+IF8tzfmBgABHgIy8eMIjBZ0CpK3q5gI7pNcDp6n4WNBng0yz3kVC9VmaYZDeQ50fuid5B6c X-Received: by 2002:a05:6a21:a584:b0:187:8d7a:76e8 with SMTP id gd4-20020a056a21a58400b001878d7a76e8mr556197pzc.16.1700054220935; Wed, 15 Nov 2023 05:17:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700054220; cv=none; d=google.com; s=arc-20160816; b=Sm/djL/mq13byKjGE5KvPQaFVi3zCWV8PRDXbH2GD2oFj4U1LkMUGnXDTNn7Ug3Gwq 0SnNjbpeYNqMvl7+RNEPuGWTs1cOWTNgbl2MjHx4gHo1mJgQ9jGSjCu3n7FFeROMv0fy ildVtqy69TZvDzKnq6qt99ZQ1pBUa7R/ldNc7aw16iLDZlzoIdehCd37O3edbSO7Rq+n U5S3w7nyozHPWKRP1+WsyWC7+3cc5ut/h8zsc0Pt9zmur0QrcTQpUIur2SjTETDWNT8a 9PE6KbvFXao7pdaLb9RiJ8sIUh0zo9gIz12o40CQFcicCb3fI0CGj3HCoFUV14pPdrr3 mRVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=4lF7aMHaWE0StDFmSjkvXf9QppPYg6hsJ7Fo37wmlDE=; fh=Dozt4b0tXu+QbIEFXzQFSF6RR2qxj3AEdXJKLwci3bA=; b=ojpcTPJNumDJ0DgiRFJr0ZxrYj7C7htaEhQKyrfPFpxbNy2TmPygNUTClu32nfoCF8 4qTesC64BN0foHpM7jLuHE1C0qwxlikv1NdrYuVR+unmDSm2cmViHY8tH2/TPhV/M2gz 99487e1wwpqyh8G6CnsBNLAiUXYR1zuDAKknMn0Hibd254ckenuIPlq+Ir35hDBY5g1M aOWtcNvxDy9+gc7Q4NUIxKTJQNoIn9lMEOYHtzGimUgd5HuoBil+S2OxyyUmeM21SZNO q/GXJ17wuBnmr62Fd08AgmOBbNVRW1V8uo3wl0DhOITW6vclI6Ch47hrtLtt6IQRgjZs a+wg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SBFJzhWN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id d9-20020a170903230900b001cc407388a8si10943179plh.337.2023.11.15.05.17.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Nov 2023 05:17:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SBFJzhWN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id DE71C80C6E95; Wed, 15 Nov 2023 05:16:49 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343888AbjKONQC (ORCPT <rfc822;heyuhang3455@gmail.com> + 28 others); Wed, 15 Nov 2023 08:16:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53700 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343852AbjKONQA (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 15 Nov 2023 08:16:00 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 717FA11D for <linux-kernel@vger.kernel.org>; Wed, 15 Nov 2023 05:15:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700054156; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=4lF7aMHaWE0StDFmSjkvXf9QppPYg6hsJ7Fo37wmlDE=; b=SBFJzhWNiZV7zMkfG2Fw00fjpD21P0bvqq+MRpluhQNpk236w0IP0kYmjhwUPubsPudiIm MnPASHVrqR+yAXSSqLmeOkxzC1wBaJzfa9OXhQ46JOwIwuD1REscOJDbwiGJAQ6jjQ8Rqz Hy0zdaz8zBauDKrIj/MQkl/FKRrn6fU= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-199-8dHQHRuwNaeqz4aXsf2O8Q-1; Wed, 15 Nov 2023 08:15:55 -0500 X-MC-Unique: 8dHQHRuwNaeqz4aXsf2O8Q-1 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-32fd8da34fbso3090604f8f.1 for <linux-kernel@vger.kernel.org>; Wed, 15 Nov 2023 05:15:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700054153; x=1700658953; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4lF7aMHaWE0StDFmSjkvXf9QppPYg6hsJ7Fo37wmlDE=; b=p2mcRmi1uoK212BakDc8UqX2aKHBKoWOfy1msa34BWXnTK5UvLmYLNUx8sRUE//NEk lYMy+tzP+YM+gW/qaNlBZwg/VJq2e7Aa5yXhY6I5HBUroiZ4mi47G+J87jhr1mme0j/I R7+bVos8i30F8Yl3kKxDt7+BfladNb0JTXPsC1PB0O2eqRIak6Ond2Nba1KqW4PbjJ3a 6adSxuSPH8emoGfeN7RtAH+tp/p1pR41Fqb3E8JPedrUjMYIQdCT7t75rWelPHcAomeu rOEMljEj+JmGHeS6q48Qf6UAM0E0jMYZK+g2HQi7M8UC3iH4NtBDidDODLJGKqx4W+oA oNbw== X-Gm-Message-State: AOJu0YwE7VNb3Uw0y28za2cCPA6FQ6L6zMBgpSqilf1M1dLMBtje1E0i dRBNsZHcbBgiKqHYPMNJiravkhASDccxuDwa10W+PiLQgblOx0H2m/rfeYNUoh79D3B4yGwIhAN XOpBUXTonakBTHgXbKKf02B5qOjfDxjHzG8W2c5BMQILhLBl+OsC4MwbijHCXVuXJSNiiF1RYer Djex3NnwI= X-Received: by 2002:a5d:64ef:0:b0:31c:8880:5d0f with SMTP id g15-20020a5d64ef000000b0031c88805d0fmr8815350wri.11.1700054153514; Wed, 15 Nov 2023 05:15:53 -0800 (PST) X-Received: by 2002:a5d:64ef:0:b0:31c:8880:5d0f with SMTP id g15-20020a5d64ef000000b0031c88805d0fmr8815312wri.11.1700054153053; Wed, 15 Nov 2023 05:15:53 -0800 (PST) Received: from localhost (205.pool92-176-231.dynamic.orange.es. [92.176.231.205]) by smtp.gmail.com with ESMTPSA id q12-20020a05600000cc00b0032db4e660d9sm10551595wrx.56.2023.11.15.05.15.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Nov 2023 05:15:52 -0800 (PST) From: Javier Martinez Canillas <javierm@redhat.com> To: linux-kernel@vger.kernel.org Cc: Maxime Ripard <mripard@kernel.org>, Bilal Elmoussaoui <belmouss@redhat.com>, Simon Ser <contact@emersion.fr>, Erico Nunes <nunes.erico@gmail.com>, Pekka Paalanen <pekka.paalanen@collabora.com>, Thomas Zimmermann <tzimmermann@suse.de>, Sima Vetter <daniel.vetter@ffwll.ch>, Javier Martinez Canillas <javierm@redhat.com>, Chia-I Wu <olvaffe@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@gmail.com>, David Airlie <airlied@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, Gurchetan Singh <gurchetansingh@chromium.org>, Jonathan Corbet <corbet@lwn.net>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, VMware Graphics Reviewers <linux-graphics-maintainer@vmware.com>, Zack Rusin <zackr@vmware.com>, dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org, virtualization@lists.linux.dev Subject: [PATCH v2 0/5] drm: Allow the damage helpers to handle buffer damage Date: Wed, 15 Nov 2023 14:15:39 +0100 Message-ID: <20231115131549.2191589-1-javierm@redhat.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Wed, 15 Nov 2023 05:16:50 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782636054637729891 X-GMAIL-MSGID: 1782636054637729891 |
Series |
drm: Allow the damage helpers to handle buffer damage
|
|
Message
Javier Martinez Canillas
Nov. 15, 2023, 1:15 p.m. UTC
Hello, This series is to fix an issue that surfaced after damage clipping was enabled for the virtio-gpu by commit 01f05940a9a7 ("drm/virtio: Enable fb damage clips property for the primary plane"). After that change, flickering artifacts was reported to be present with both weston and wlroots wayland compositors when running in a virtual machine. The cause was identified by Sima Vetter, who pointed out that virtio-gpu does per-buffer uploads and for this reason it needs to do a buffer damage handling, instead of frame damage handling. Their suggestion was to extend the damage helpers to cover that case and given that there's isn't a buffer damage accumulation algorithm (e.g: buffer age), just do a full plane update if the framebuffer that is attached to a plane changed since the last plane update (page-flip). It is a v2 that addresses issues pointed out by Thomas Zimmermann in v1: https://lists.freedesktop.org/archives/dri-devel/2023-November/430138.html Patch #1 adds a ignore_damage_clips field to struct drm_plane_state to be set by drivers that want the damage helpers to ignore the damage clips. Patch #2 fixes the virtio-gpu damage handling logic by asking the damage helper to ignore the damage clips if the framebuffer attached to a plane has changed since the last page-flip. Patch #3 does the same but for the vmwgfx driver that also needs to handle buffer damage and should have the same issue (although I haven't tested it due not having a VMWare setup). Patch #4 adds to the KMS damage tracking kernel-doc some paragraphs about damage tracking types and references to links that explain frame damage vs buffer damage. Finally patch #5 adds an item to the DRM todo, about the need to implement some buffer damage accumulation algorithm instead of just doing full plane updates in this case. Because commit 01f05940a9a7 landed in v6.4, the first 2 patches are marked as Fixes and Cc stable. I've tested this on a VM with weston, was able to reproduce the issue reported and the patches did fix the problem. Best regards, Javier Changes in v2: - Add a struct drm_plane_state .ignore_damage_clips to set in the plane's .atomic_check, instead of having different helpers (Thomas Zimmermann). - Set struct drm_plane_state .ignore_damage_clips in virtio-gpu plane's .atomic_check instead of using a different helpers (Thomas Zimmermann). - Set struct drm_plane_state .ignore_damage_clips in vmwgfx plane's .atomic_check instead of using a different helpers (Thomas Zimmermann). Javier Martinez Canillas (5): drm: Allow drivers to indicate the damage helpers to ignore damage clips drm/virtio: Disable damage clipping if FB changed since last page-flip drm/vmwgfx: Disable damage clipping if FB changed since last page-flip drm/plane: Extend damage tracking kernel-doc drm/todo: Add entry about implementing buffer age for damage tracking Documentation/gpu/todo.rst | 20 ++++++++++++++++++++ drivers/gpu/drm/drm_damage_helper.c | 3 ++- drivers/gpu/drm/drm_plane.c | 20 ++++++++++++++++++++ drivers/gpu/drm/virtio/virtgpu_plane.c | 10 ++++++++++ drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 11 +++++++++++ include/drm/drm_plane.h | 8 ++++++++ 6 files changed, 71 insertions(+), 1 deletion(-)
Comments
On Wed, 2023-11-15 at 14:15 +0100, Javier Martinez Canillas wrote: > Hello, > > This series is to fix an issue that surfaced after damage clipping was > enabled for the virtio-gpu by commit 01f05940a9a7 ("drm/virtio: Enable > fb damage clips property for the primary plane"). > > After that change, flickering artifacts was reported to be present with > both weston and wlroots wayland compositors when running in a virtual > machine. The cause was identified by Sima Vetter, who pointed out that > virtio-gpu does per-buffer uploads and for this reason it needs to do > a buffer damage handling, instead of frame damage handling. > > Their suggestion was to extend the damage helpers to cover that case > and given that there's isn't a buffer damage accumulation algorithm > (e.g: buffer age), just do a full plane update if the framebuffer that > is attached to a plane changed since the last plane update (page-flip). > > It is a v2 that addresses issues pointed out by Thomas Zimmermann in v1: > https://lists.freedesktop.org/archives/dri-devel/2023-November/430138.html > > Patch #1 adds a ignore_damage_clips field to struct drm_plane_state to be > set by drivers that want the damage helpers to ignore the damage clips. > > Patch #2 fixes the virtio-gpu damage handling logic by asking the damage > helper to ignore the damage clips if the framebuffer attached to a plane > has changed since the last page-flip. > > Patch #3 does the same but for the vmwgfx driver that also needs to handle > buffer damage and should have the same issue (although I haven't tested it > due not having a VMWare setup). > > Patch #4 adds to the KMS damage tracking kernel-doc some paragraphs about > damage tracking types and references to links that explain frame damage vs > buffer damage. > > Finally patch #5 adds an item to the DRM todo, about the need to implement > some buffer damage accumulation algorithm instead of just doing full plane > updates in this case. > > Because commit 01f05940a9a7 landed in v6.4, the first 2 patches are marked > as Fixes and Cc stable. > > I've tested this on a VM with weston, was able to reproduce the issue > reported and the patches did fix the problem. > > Best regards, > Javier > > Changes in v2: > - Add a struct drm_plane_state .ignore_damage_clips to set in the plane's > .atomic_check, instead of having different helpers (Thomas Zimmermann). > - Set struct drm_plane_state .ignore_damage_clips in virtio-gpu plane's > .atomic_check instead of using a different helpers (Thomas Zimmermann). > - Set struct drm_plane_state .ignore_damage_clips in vmwgfx plane's > .atomic_check instead of using a different helpers (Thomas Zimmermann). The series looks good to me, thanks for tackling this. I'm surprised that we don't have any IGT tests for this. Seems like it shouldn't be too hard to test it in a generic way with just a couple of dumb buffers. z
Zack Rusin <zackr@vmware.com> writes: Hello Zack, > On Wed, 2023-11-15 at 14:15 +0100, Javier Martinez Canillas wrote: [...] >> >> Changes in v2: >> - Add a struct drm_plane_state .ignore_damage_clips to set in the plane's >> .atomic_check, instead of having different helpers (Thomas Zimmermann). >> - Set struct drm_plane_state .ignore_damage_clips in virtio-gpu plane's >> .atomic_check instead of using a different helpers (Thomas Zimmermann). >> - Set struct drm_plane_state .ignore_damage_clips in vmwgfx plane's >> .atomic_check instead of using a different helpers (Thomas Zimmermann). > > The series looks good to me, thanks for tackling this. I'm surprised that we don't Thanks. Can I get your r-b or a-b ? > have any IGT tests for this. Seems like it shouldn't be too hard to test it in a > generic way with just a couple of dumb buffers. > Yes, I haven't looked at it but also think that shouldn't be that hard. > z
Hi Javier, please take my Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> for the whole patch set. Maybe consider my comment on patch 4. Best regards Thomas Am 15.11.23 um 14:15 schrieb Javier Martinez Canillas: > Hello, > > This series is to fix an issue that surfaced after damage clipping was > enabled for the virtio-gpu by commit 01f05940a9a7 ("drm/virtio: Enable > fb damage clips property for the primary plane"). > > After that change, flickering artifacts was reported to be present with > both weston and wlroots wayland compositors when running in a virtual > machine. The cause was identified by Sima Vetter, who pointed out that > virtio-gpu does per-buffer uploads and for this reason it needs to do > a buffer damage handling, instead of frame damage handling. > > Their suggestion was to extend the damage helpers to cover that case > and given that there's isn't a buffer damage accumulation algorithm > (e.g: buffer age), just do a full plane update if the framebuffer that > is attached to a plane changed since the last plane update (page-flip). > > It is a v2 that addresses issues pointed out by Thomas Zimmermann in v1: > https://lists.freedesktop.org/archives/dri-devel/2023-November/430138.html > > Patch #1 adds a ignore_damage_clips field to struct drm_plane_state to be > set by drivers that want the damage helpers to ignore the damage clips. > > Patch #2 fixes the virtio-gpu damage handling logic by asking the damage > helper to ignore the damage clips if the framebuffer attached to a plane > has changed since the last page-flip. > > Patch #3 does the same but for the vmwgfx driver that also needs to handle > buffer damage and should have the same issue (although I haven't tested it > due not having a VMWare setup). > > Patch #4 adds to the KMS damage tracking kernel-doc some paragraphs about > damage tracking types and references to links that explain frame damage vs > buffer damage. > > Finally patch #5 adds an item to the DRM todo, about the need to implement > some buffer damage accumulation algorithm instead of just doing full plane > updates in this case. > > Because commit 01f05940a9a7 landed in v6.4, the first 2 patches are marked > as Fixes and Cc stable. > > I've tested this on a VM with weston, was able to reproduce the issue > reported and the patches did fix the problem. > > Best regards, > Javier > > Changes in v2: > - Add a struct drm_plane_state .ignore_damage_clips to set in the plane's > .atomic_check, instead of having different helpers (Thomas Zimmermann). > - Set struct drm_plane_state .ignore_damage_clips in virtio-gpu plane's > .atomic_check instead of using a different helpers (Thomas Zimmermann). > - Set struct drm_plane_state .ignore_damage_clips in vmwgfx plane's > .atomic_check instead of using a different helpers (Thomas Zimmermann). > > Javier Martinez Canillas (5): > drm: Allow drivers to indicate the damage helpers to ignore damage > clips > drm/virtio: Disable damage clipping if FB changed since last page-flip > drm/vmwgfx: Disable damage clipping if FB changed since last page-flip > drm/plane: Extend damage tracking kernel-doc > drm/todo: Add entry about implementing buffer age for damage tracking > > Documentation/gpu/todo.rst | 20 ++++++++++++++++++++ > drivers/gpu/drm/drm_damage_helper.c | 3 ++- > drivers/gpu/drm/drm_plane.c | 20 ++++++++++++++++++++ > drivers/gpu/drm/virtio/virtgpu_plane.c | 10 ++++++++++ > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 11 +++++++++++ > include/drm/drm_plane.h | 8 ++++++++ > 6 files changed, 71 insertions(+), 1 deletion(-) > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)