On Thu, Feb 4, 2021, 18:18 Daniel Vetter <dan...@ffwll.ch> wrote:
> On Thu, Feb 4, 2021 at 5:03 PM Toni Spets <toni.sp...@iki.fi> wrote:
> >
> >
> >
> > On Thu, Feb 4, 2021, 17:20 Daniel Vetter <dan...@ffwll.ch> wrote:
> >>
> >> On Wed, Feb 03, 2021 at 09:53:40PM +0200, Toni Spets wrote:
> >> > The blocking implementation of the dirtyfb ioctl is extremely slow
> when
> >> > used for damage tracking on RK3399. If this implementation is in
> place Xorg
> >> > will default to using it and will slow down considerably when doing a
> lot
> >> > of small draws. This is most apparent with the fvwm window manager on
> >> > startup where it will almost lock up for many seconds seconds on
> RK3399.
> >> >
> >> > Removing this implementation did not cause any visible issues on
> RK3399 but
> >> > it did fix the performance issues on Xorg as it will disable damage
> >> > tracking when the ioctl returns it's not supported.
> >>
> >> Then you don't have a manual update panel.
> >>
> >> Iirc there were patches to make this faster in recent kernels, on what
> >> kernels did you try this?
> >
> >
> > Latest was 5.10.12. If there are fixes for this in later kernels I will
> definitely try it out.
>
> Hm I thought it landed already. But checking it the optimization was
> for fbdev to batch up updates more (because that one doesn't even
> try), not direct X usage. So your X should work faster if you use
> fbdev as backend (just as an experiment).
>
Yeah, I used fbdev to test before which got me down this path to look up
what's wrong with the modesetting driver.
Fbdev runs flawlessly but then we lose panfrost for other acceleration so
it's unfortunately not a silver bullet.
> >> Also X should only call this in the blocker handler, not all the time.
> >
> >
> > It does but fvwm is an example that forces it to be called a lot and
> it's slow enough to cause significant issues.
> >
> >>
> >> So yeah we need to make this faster, not break manual update panels.
> >
> >
> > Pardon my ignorance but while making this operation faster will indeed
> make it better wouldn't the correct behavior be to know if a panel requires
> this or not?
>
> Not impossible, but there's a pile of layers in the way. And generally
> frontbuffer rendering doesn't see a lot of love, since aside from
> bootloaders and old sckool X window systems without compositors,
> they're not really seeing any use. Everything Wayland or composited
> desktops is double-buffered and fast.
>
It's not this black and white, unfortunately. Compositing even on Xorg is
slower than not using it at all at least on Xfce where currently this
hardware gets the best results with this patch applied and compositor off.
Maybe the implementation is just bad on Xfce?
> For fbdev we're also doing the dirty tracking now at a driver level
> (using the helpers), unconditionally whether the given hw actually
> needs it or not.
>
> More pragmatic approach would be to throw a kernel thread at this
> problem. Will be tricky since we need to make sure that from
> userspace's pov nothing breaks, which is always a bit an issue when
> making things more asynchronous. Specifically we need to make sure
> that userspace doesn't get ahead of the kernel, so might need to
> require that we only batch up updates for the same framebuffer object,
> but stall when we switch.
>
> The locking for this will get interesting.
>
Sounds like an awful lot of work for a niche use. Although if Wayland ends
up calling this even every now and then it may prove to be useful.
I haven't done any testing or benchmarking on Wayland so I have no
knowledge if this makes any difference there.
Maybe this could solved in Xorg by having an option to disable damage
tracking manually, though ideally no manual setup would be needed and I
doubt anyone wants new options for the modesetting driver for an edge case
like this.
Don't really know where to go from here. Wouldn't want to carry this patch
manually just to get a well working X either.
Thanks for the insight and I'm happy to test any solution if something
comes up!
> Cheers, Daniel
>
> > Making a low performance device wait any extra time for no reason
> doesn't sound like the correct fix either.
> >
> > I'm not defending the patch itself as I don't have enough understanding
> of the drm or kernel so if it's indeed definitely breaking something then
> of course it can't be used as is.
> >
> > Thanks.
> >
> >
> >> -Daniel
> >>
> >> >
> >> > --
> >> > Toni Spets
> >>
> >> > From 79984ee67c801f552e9eaf4d0cfb62101d1f0f2e Mon Sep 17 00:00:00 2001
> >> > From: Toni Spets <toni.sp...@iki.fi>
> >> > Date: Wed, 3 Feb 2021 21:14:50 +0200
> >> > Subject: [PATCH] drm/rockchip: remove atomic helper dirtyfb
> >> >
> >> > ---
> >> > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 1 -
> >> > 1 file changed, 1 deletion(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> >> > index 3aa37e177667..2554fd1c8aeb 100644
> >> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> >> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> >> > @@ -21,7 +21,6 @@
> >> > static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
> >> > .destroy = drm_gem_fb_destroy,
> >> > .create_handle = drm_gem_fb_create_handle,
> >> > - .dirty = drm_atomic_helper_dirtyfb,
> >> > };
> >> >
> >> > static struct drm_framebuffer *
> >> > --
> >> > 2.27.0
> >> >
> >>
> >> > _______________________________________________
> >> > dri-devel mailing list
> >> > dri-devel@lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >>
> >>
> >> --
> >> Daniel Vetter
> >> Software Engineer, Intel Corporation
> >> http://blog.ffwll.ch
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
