On Thu, 2021-09-09 at 23:28 +0300, Ville Syrjälä wrote:
> On Thu, Sep 09, 2021 at 08:23:20PM +0000, Souza, Jose wrote:
> > On Thu, 2021-09-09 at 23:20 +0300, Ville Syrjälä wrote:
> > > On Thu, Sep 09, 2021 at 12:49:16PM -0700, José Roberto de Souza wrote:
> > > > By now all the userspace applications should have migrated to atomic
> > > > or at least be calling DRM_IOCTL_MODE_DIRTYFB.
> > > >
> > > > With that we can kill frontbuffer rendering support in i915 for
> > > > modern platforms.
> > > >
> > > > So here converting legacy APIs into atomic commits so it can be
> > > > properly handled by driver i915.
> > > >
> > > > Several IGT tests will fail with this changes, because some tests
> > > > were stressing those frontbuffer rendering scenarios that no userspace
> > > > should be using by now, fixes to IGT should be sent soon.
> > > >
> > >
> > > I just gave this a try here and it's unusable. glxgears went from
> > > 9000 to 120 fps (was expecting 60fps tbh, not sure why I get
> > > double), everything lags like mad, if I drag a window around
> > > glxgears/other windows stop updating entirely, etc. NAK
> >
> > Can you share your setup? What GPU? Desktop environment? Mesa version? resolutions of sinks?
> > Will try it in my end.
>
> Doesn't really matter as long as you don't have a compositor making a
> mess of things. This machine is a cfl running mate w/ compositor off,
> and some 1920x1200 display.
>
Making drm_atomic_helper_dirtyfb() do a non-blocking atomic commit makes user experience pretty similar to the one with compositing enabled:
drm_atomic_commit() + compositor off: https://youtu.be/NBt6smXs99U
drm_atomic_nonblocking_commit() + compositor off: https://youtu.be/QiMhkeGX_L8
drm_atomic_nonblocking_commit() + compositor on: https://youtu.be/KdpJyJ5k6sQ
I do not completly agree with the comment in drm_atomic_helper_dirtyfb() about why it uses a blocking implementation.
With frontbuffer rendering the registers are programmed but the content could only show up for user a whole frame later.
Perhaps if this solutions is accetable we could have a non-blocking version of drm_atomic_helper_dirtyfb() so the drivers current using it don't have
their behavior changed.
From 47c5b1f918363686cd8cf51239a298dd78f9fae6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Roberto=20de=20Souza?= <jose.souza@xxxxxxxxx>
Date: Mon, 13 Sep 2021 14:16:31 -0700
Subject: [PATCH] HACK: Make drm_atomic_helper_dirtyfb() non-blocking
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Hack just to show up that making non-blocking atomic commits helps
to compensate the performance regressions when converting frotbuffer
dirty calls to drm_atomic_helper_dirtyfb() in desktop enviroments
without compositing.
I know that this goes against the documentation in
drm_atomic_helper_dirtyfb().
Signed-off-by: José Roberto de Souza <jose.souza@xxxxxxxxx>
---
drivers/gpu/drm/drm_damage_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_damage_helper.c b/drivers/gpu/drm/drm_damage_helper.c
index 8eeff0c7bdd47..1740144674ce3 100644
--- a/drivers/gpu/drm/drm_damage_helper.c
+++ b/drivers/gpu/drm/drm_damage_helper.c
@@ -177,7 +177,7 @@ int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb,
damage);
}
- ret = drm_atomic_commit(state);
+ ret = drm_atomic_nonblocking_commit(state);
out:
if (ret == -EDEADLK) {
--
2.33.0
