linux-kernel - RE: [RFC 0/3] drm: page-flip with 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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN6PR05MB31068D4ECB01090CD6FA682EBABB0@BN6PR05MB3106.namprd05.prod.outlook.com>
Date:   Thu, 5 Apr 2018 18:43:22 +0000
From:   Deepak Singh Rawat <drawat@...are.com>
To:     Daniel Vetter <daniel@...ll.ch>
CC:     "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        Thomas Hellstrom <thellstrom@...are.com>,
        Sinclair Yeh <syeh@...are.com>,
        linux-graphics-maintainer <linux-graphics-maintainer@...are.com>,
        "ville.syrjala@...ux.intel.com" <ville.syrjala@...ux.intel.com>,
        "lukasz.spintzyk@...playlink.com" <lukasz.spintzyk@...playlink.com>,
        "noralf@...nnes.org" <noralf@...nnes.org>,
        "robdclark@...il.com" <robdclark@...il.com>,
        "gustavo@...ovan.org" <gustavo@...ovan.org>,
        "maarten.lankhorst@...ux.intel.com" 
        <maarten.lankhorst@...ux.intel.com>,
        "seanpaul@...omium.org" <seanpaul@...omium.org>,
        "airlied@...ux.ie" <airlied@...ux.ie>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC 0/3] drm: page-flip with damage

> 
> On Wed, Apr 04, 2018 at 04:49:05PM -0700, Deepak Rawat wrote:
> > Hi All,
> >
> > This is extension to Lukasz Spintzyk earlier draft of damage interface for
> drm.
> > Bascially a new plane property is added called "DAMAGE_CLIPS" which is
> simply
> > an array of drm_rect (exported to userspace as drm_mode_rect). The clips
> > represents damage in framebuffer coordinate of attached fb to the plane.
> >
> > Helper iterator is added to traverse the damage rectangles and get the
> damage
> > clips in framebuffer, plane or crtc coordinates as need by driver
> > implementation. Finally a helper to reset damage in case need full update is
> > required. Drivers interested in page-flip with damage should call this from
> > atomic_check hook.
> >
> > With the RFC for atomic implementation of dirtyfb ioctl I was thinking
> > should we need to consider dirty_fb flags, especially
> > DRM_MODE_FB_DIRTY_ANNOTATE_COPY to be passed with atomic
> > DAMAGE_CLIPS property blob? I didn't considered that untill now. If no
> driver
> > uses that in my opinion for simplicity this can be ignored?
> 
> Last time I've checked no driver nor userspace really used this. I'd drop
> it for the new uapi like you've done.

Thanks Daniel for the review.
Agreed, will drop dirty_fb flags unless someone has any objection.

> 
> > About overlaping of damage rectangles is also not finalized. This really
> > depends on driver specific implementation and can be left open-ended?
> 
> Overlapping is userspace being stupid imo :-) I guess we should say that
> drivers should at least not fall over overlapping rects, and if they can't
> handle them, either coalesce into one big rect, or split them on their own
> somehow.

I think the best is to suggest user-space to not send overlapped rects. But
as someone earlier suggested it is hard or I should say unnecessary check
to enforce this in driver.

> 
> > My knowledge is limited to vmwgfx so would like to hear about other
> driver use
> > cases and this can be modified in keeping other drivers need.
> >
> > Going forward driver implementation for vmwgfx and user-space
> implementation
> > of kmscube/weston will be next step to test the changes.
> 
> I think an implementation for -modesetting and weston would be perfect.
> Kmscube has very littel value for damage tracking purposes (it's not a
> full compositor, just renders new frame each scene). And for kms I'm not a
> fan of using vendor-specific drivers to demonstrate new generic uapi - way
> too big chances you're making some vendor driver specific hardcoded
> assumption that doesn't hold anywhere else. Also makes it harder for
> others to test-implement your uapi in their drivers.
> -Daniel

Agreed implementation in modesetting and Weston and for kernel part as
I read in another mail dirty_fb implementation is also a good use-case.

> 
> >
> > Thanks,
> > Deepak
> >
> > Deepak Rawat (2):
> >   drm: Add helper iterator functions to iterate over plane damage.
> >   drm: Add helper to validate damage during modeset_check
> >
> > Lukasz Spintzyk (1):
> >   drm: Add DAMAGE_CLIPS property to plane
> >
> >  drivers/gpu/drm/drm_atomic.c        |  42 +++++++++
> >  drivers/gpu/drm/drm_atomic_helper.c | 173
> ++++++++++++++++++++++++++++++++++++
> >  drivers/gpu/drm/drm_mode_config.c   |   5 ++
> >  drivers/gpu/drm/drm_plane.c         |  12 +++
> >  include/drm/drm_atomic_helper.h     |  41 +++++++++
> >  include/drm/drm_mode_config.h       |  15 ++++
> >  include/drm/drm_plane.h             |  16 ++++
> >  include/uapi/drm/drm_mode.h         |  15 ++++
> >  8 files changed, 319 insertions(+)
> >
> > --
> > 2.7.4
> >
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__blog.ffwll.ch&d=DwIBAg&c=uilaK90D4TOVoH58JNXRgQ&r=zOOG28inJK
> 0762SxAf-
> cyZdStnd2NQpRu98lJP2iYGw&m=CrefGziKAEk50MpTaNv64iDljHY7GesUlFHZc
> hWpiqI&s=gFk0ko5cD_cnIyPuZOrqyAwLsmTt9PiSDbWdHoi-8cU&e=