From: Deepak Singh Rawat <drawat@vmware.com> To: Lukasz Spintzyk <lukasz.spintzyk@displaylink.com> Cc: "airlied@linux.ie" <airlied@linux.ie>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, linux-graphics-maintainer <linux-graphics-maintainer@vmware.com>, "robdclark@gmail.com" <robdclark@gmail.com>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, Thomas Hellstrom <thellstrom@vmware.com>, Sinclair Yeh <syeh@vmware.com> Subject: RE: [RFC 0/3] drm: page-flip with damage Date: Tue, 10 Apr 2018 18:56:12 +0000 [thread overview] Message-ID: <SN6PR05MB39502480F2F2F8CA12A45848BABE0@SN6PR05MB3950.namprd05.prod.outlook.com> (raw) In-Reply-To: <5f3e1c8a-d2b9-41f9-46f6-2b7f8c736de8@displaylink.com> >Hi, > >Many thanks that you have picked it up. >Unfortunately I didn't had time to work on it for a while. > >I am ok with what you have done, ihmo the review is going in good direction. >I will try not to miss your update of it. >From my side I can say that damage rects with frame-buffer coordinates are perfectly fine for DisplayLink case. > >Btw I have noticed that there is also a patch from Rob Clark that is supplying helper for legacy dirtyfb callback. >Maybe we should unify the naming of the rects. Here we have "damage_clips", Clark's patch has 'dirty_rects' notion. >On other hand existing legacy dirtyfb callback in drm_framebuffer_funcs is also using 'clip_rects' :). The reason to name it damage is inspired by eglSwapBuffersWithDamageKHR which user-space will be calling before submitting a page-flip. So it makes naming consistent and in sync with user-space. > >Thanks > >Łukasz Spintzyk > >On 05/04/2018 01:49, 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? > >About overlaping of damage rectangles is also not finalized. This really >depends on driver specific implementation and can be left open-ended? > >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. > >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 >
WARNING: multiple messages have this Message-ID (diff)
From: Deepak Singh Rawat <drawat@vmware.com> To: Lukasz Spintzyk <lukasz.spintzyk@displaylink.com> Cc: Thomas Hellstrom <thellstrom@vmware.com>, "airlied@linux.ie" <airlied@linux.ie>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, linux-graphics-maintainer <linux-graphics-maintainer@vmware.com> Subject: RE: [RFC 0/3] drm: page-flip with damage Date: Tue, 10 Apr 2018 18:56:12 +0000 [thread overview] Message-ID: <SN6PR05MB39502480F2F2F8CA12A45848BABE0@SN6PR05MB3950.namprd05.prod.outlook.com> (raw) In-Reply-To: <5f3e1c8a-d2b9-41f9-46f6-2b7f8c736de8@displaylink.com> >Hi, > >Many thanks that you have picked it up. >Unfortunately I didn't had time to work on it for a while. > >I am ok with what you have done, ihmo the review is going in good direction. >I will try not to miss your update of it. >From my side I can say that damage rects with frame-buffer coordinates are perfectly fine for DisplayLink case. > >Btw I have noticed that there is also a patch from Rob Clark that is supplying helper for legacy dirtyfb callback. >Maybe we should unify the naming of the rects. Here we have "damage_clips", Clark's patch has 'dirty_rects' notion. >On other hand existing legacy dirtyfb callback in drm_framebuffer_funcs is also using 'clip_rects' :). The reason to name it damage is inspired by eglSwapBuffersWithDamageKHR which user-space will be calling before submitting a page-flip. So it makes naming consistent and in sync with user-space. > >Thanks > >Łukasz Spintzyk > >On 05/04/2018 01:49, 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? > >About overlaping of damage rectangles is also not finalized. This really >depends on driver specific implementation and can be left open-ended? > >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. > >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 > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-04-10 18:56 UTC|newest] Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-04 23:49 [RFC 0/3] drm: page-flip with damage Deepak Rawat 2018-04-04 23:49 ` Deepak Rawat 2018-04-04 23:49 ` [RFC 1/3] drm: Add DAMAGE_CLIPS property to plane Deepak Rawat 2018-04-04 23:49 ` Deepak Rawat 2018-04-05 7:35 ` Daniel Vetter 2018-04-05 9:00 ` Thomas Hellstrom 2018-04-05 9:00 ` Thomas Hellstrom 2018-04-05 10:03 ` Daniel Vetter 2018-04-05 10:03 ` Daniel Vetter 2018-04-05 11:35 ` Thomas Hellstrom 2018-04-05 13:47 ` Daniel Vetter 2018-04-05 13:47 ` Daniel Vetter 2018-04-05 13:58 ` Thomas Hellstrom 2018-04-05 11:42 ` Thomas Hellstrom 2018-04-05 11:42 ` Thomas Hellstrom 2018-04-05 13:49 ` Daniel Vetter 2018-04-05 13:49 ` Daniel Vetter 2018-04-05 23:07 ` Deepak Singh Rawat 2018-04-05 23:07 ` Deepak Singh Rawat 2018-04-09 8:33 ` Daniel Vetter 2018-04-09 8:33 ` Daniel Vetter 2018-04-09 16:44 ` Deepak Singh Rawat 2018-04-10 8:10 ` Lukasz Spintzyk 2018-04-04 23:49 ` [RFC 2/3] drm: Add helper iterator functions to iterate over plane damage Deepak Rawat 2018-04-04 23:49 ` Deepak Rawat 2018-04-05 7:52 ` Daniel Vetter 2018-04-05 7:52 ` Daniel Vetter 2018-04-05 8:49 ` Thomas Hellstrom 2018-04-05 8:49 ` Thomas Hellstrom 2018-04-05 10:10 ` Daniel Vetter 2018-04-05 10:10 ` Daniel Vetter 2018-04-05 11:51 ` Thomas Hellstrom 2018-04-05 11:51 ` Thomas Hellstrom 2018-04-05 13:52 ` Daniel Vetter 2018-04-05 13:52 ` Daniel Vetter 2018-04-05 8:51 ` Thomas Hellstrom 2018-04-05 8:51 ` Thomas Hellstrom 2018-04-05 13:54 ` Daniel Vetter 2018-04-05 13:54 ` Daniel Vetter 2018-04-05 23:59 ` Deepak Singh Rawat 2018-04-05 23:59 ` Deepak Singh Rawat 2018-04-09 8:35 ` Daniel Vetter 2018-04-09 8:35 ` Daniel Vetter 2018-04-05 23:19 ` Deepak Singh Rawat 2018-04-05 23:19 ` Deepak Singh Rawat 2018-04-05 17:55 ` Sinclair Yeh 2018-04-05 17:55 ` Sinclair Yeh 2018-04-04 23:49 ` [RFC 3/3] drm: Add helper to validate damage during modeset_check Deepak Rawat 2018-04-04 23:49 ` Deepak Rawat 2018-04-05 7:59 ` Daniel Vetter 2018-04-05 7:59 ` Daniel Vetter 2018-04-05 23:55 ` Deepak Singh Rawat 2018-04-05 23:55 ` Deepak Singh Rawat 2018-04-09 8:38 ` Daniel Vetter 2018-04-09 8:38 ` Daniel Vetter 2018-04-05 7:19 ` [RFC 0/3] drm: page-flip with damage Daniel Vetter 2018-04-05 7:19 ` Daniel Vetter 2018-04-05 18:43 ` Deepak Singh Rawat 2018-04-05 18:43 ` Deepak Singh Rawat 2018-04-10 8:10 ` Lukasz Spintzyk 2018-04-10 18:56 ` Deepak Singh Rawat [this message] 2018-04-10 18:56 ` Deepak Singh Rawat
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=SN6PR05MB39502480F2F2F8CA12A45848BABE0@SN6PR05MB3950.namprd05.prod.outlook.com \ --to=drawat@vmware.com \ --cc=airlied@linux.ie \ --cc=dri-devel@lists.freedesktop.org \ --cc=linux-graphics-maintainer@vmware.com \ --cc=linux-kernel@vger.kernel.org \ --cc=lukasz.spintzyk@displaylink.com \ --cc=robdclark@gmail.com \ --cc=syeh@vmware.com \ --cc=thellstrom@vmware.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.