Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Deepak Singh Rawat <drawat@vmware.com>
To:     Daniel Vetter <daniel@ffwll.ch>
CC:     "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>,
        Thomas Hellstrom <thellstrom@vmware.com>,
        Sinclair Yeh <syeh@vmware.com>,
        linux-graphics-maintainer <linux-graphics-maintainer@vmware.com>,
        "ville.syrjala@linux.intel.com" <ville.syrjala@linux.intel.com>,
        "lukasz.spintzyk@displaylink.com" <lukasz.spintzyk@displaylink.com>,
        "noralf@tronnes.org" <noralf@tronnes.org>,
        "robdclark@gmail.com" <robdclark@gmail.com>,
        "gustavo@padovan.org" <gustavo@padovan.org>,
        "maarten.lankhorst@linux.intel.com" 
        <maarten.lankhorst@linux.intel.com>,
        "seanpaul@chromium.org" <seanpaul@chromium.org>,
        "airlied@linux.ie" <airlied@linux.ie>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [RFC 0/3] drm: page-flip with damage
Thread-Topic: [RFC 0/3] drm: page-flip with damage
Thread-Index: AQHTzG/KwKs3+5anc0ah+4EEcE3MZaPxxCCAgAC8dIA=
Date:   Thu, 5 Apr 2018 18:43:22 +0000
Message-ID: <BN6PR05MB31068D4ECB01090CD6FA682EBABB0@BN6PR05MB3106.namprd05.prod.outlook.com>
References: <1522885748-67122-1-git-send-email-drawat@vmware.com>
 <20180405071957.GO3881@phenom.ffwll.local>
In-Reply-To: <20180405071957.GO3881@phenom.ffwll.local>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: vmware.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6998dc20-4519-473a-5ec7-08d59b251bbc
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 18:43:22.2957
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3665
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>=20
> 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 clip=
s
> > 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 upda=
te 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?
>=20
> 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.

>=20
> > About overlaping of damage rectangles is also not finalized. This reall=
y
> > depends on driver specific implementation and can be left open-ended?
>=20
> 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 ow=
n
> 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.

>=20
> > 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.
>=20
> 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 - wa=
y
> 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.

>=20
> >
> > 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
> >
>=20
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-
> 3A__blog.ffwll.ch&d=3DDwIBAg&c=3DuilaK90D4TOVoH58JNXRgQ&r=3DzOOG28inJK
> 0762SxAf-
> cyZdStnd2NQpRu98lJP2iYGw&m=3DCrefGziKAEk50MpTaNv64iDljHY7GesUlFHZc
> hWpiqI&s=3DgFk0ko5cD_cnIyPuZOrqyAwLsmTt9PiSDbWdHoi-8cU&e=3D