linux-kernel - Re: [PATCH 0/6] drm: Allow the damage helpers to handle buffer damage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 14 Nov 2023 17:36:32 +0100
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     Javier Martinez Canillas <javierm@...hat.com>,
        linux-kernel@...r.kernel.org
Cc:     Pekka Paalanen <pekka.paalanen@...labora.com>,
        dri-devel@...ts.freedesktop.org, Jonathan Corbet <corbet@....net>,
        Bilal Elmoussaoui <belmouss@...hat.com>,
        linux-doc@...r.kernel.org, Maxime Ripard <mripard@...nel.org>,
        Gurchetan Singh <gurchetansingh@...omium.org>,
        VMware Graphics Reviewers 
        <linux-graphics-maintainer@...are.com>,
        Gerd Hoffmann <kraxel@...hat.com>,
        Sima Vetter <daniel.vetter@...ll.ch>,
        David Airlie <airlied@...hat.com>,
        virtualization@...ts.linux-foundation.org,
        Erico Nunes <nunes.erico@...il.com>
Subject: Re: [PATCH 0/6] drm: Allow the damage helpers to handle buffer damage

Hi

Am 14.11.23 um 17:28 schrieb Javier Martinez Canillas:
> Thomas Zimmermann <tzimmermann@...e.de> writes:
> 
>> Hi Javier
>>
>> Am 09.11.23 um 18:24 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.
>>
>> I'm having problem understanding the types of damage. You never say what
>> buffer damage is. I also don't know what a frame is in this context.
>>
>> Regular damage handling marks parts of a plane as dirty/damaged. That is
>> per-plane damage handling. The individual planes more or less
>> independent from each other.
>>
>> Buffer damage, I guess, marks the underlying buffer as dirty and
>> requires synchronization of the buffer with some backing storage. The
>> planes using that buffer are then updated more or less automatically.
>>
>> Is that right?
>>
> 
> In both cases the damage tracking information is the same, they mark
> the damaged regions on the plane in framebuffer coordinates of the
> framebuffer attached to the plane.
> 
> The problem as far as I understand is whether the driver expects that
> to determine the area that changed in the plane (and a plane flush is
> enough) or the area that changed since that same buffer was last used.
> 
>> And why does it flicker? Is there old data stored somewhere?
>>
> 
> It flickers because the framebuffer changed and so the damage tracking
> is not used correctly to flush the damaged areas to the backing storage.

I think I got it from the links in patch 5.  In out other drivers, 
there's a single backing storage for each plane (for example in the 
video memory). Here, there's a backing storage for each buffer. On page 
flips, the plane changes its backing storage.  Our GEM buffer is up to 
date, but the respective backing storage is missing all the intermediate 
changes.

If I'm not mistaken, an entirely different solution would be to 
implement a per-plane back storage in these drivers.

Best regards
Thomas

> 
> This is my understanding at least, please Sima or Simon correct me if I
> got this wrong.
> 
>> Best regards
>> Thomas
>>
> 

-- 
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)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (841 bytes)