<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 4, 2021, 18:18 Daniel Vetter <<a href="mailto:daniel@ffwll.ch" target="_blank" rel="noreferrer">daniel@ffwll.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Feb 4, 2021 at 5:03 PM Toni Spets <<a href="mailto:toni.spets@iki.fi" rel="noreferrer noreferrer" target="_blank">toni.spets@iki.fi</a>> wrote:<br>
><br>
><br>
><br>
> On Thu, Feb 4, 2021, 17:20 Daniel Vetter <<a href="mailto:daniel@ffwll.ch" rel="noreferrer noreferrer" target="_blank">daniel@ffwll.ch</a>> wrote:<br>
>><br>
>> On Wed, Feb 03, 2021 at 09:53:40PM +0200, Toni Spets wrote:<br>
>> > The blocking implementation of the dirtyfb ioctl is extremely slow when<br>
>> > used for damage tracking on RK3399. If this implementation is in place Xorg<br>
>> > will default to using it and will slow down considerably when doing a lot<br>
>> > of small draws. This is most apparent with the fvwm window manager on<br>
>> > startup where it will almost lock up for many seconds seconds on RK3399.<br>
>> ><br>
>> > Removing this implementation did not cause any visible issues on RK3399 but<br>
>> > it did fix the performance issues on Xorg as it will disable damage<br>
>> > tracking when the ioctl returns it's not supported.<br>
>><br>
>> Then you don't have a manual update panel.<br>
>><br>
>> Iirc there were patches to make this faster in recent kernels, on what<br>
>> kernels did you try this?<br>
><br>
><br>
> Latest was 5.10.12. If there are fixes for this in later kernels I will definitely try it out.<br>
<br>
Hm I thought it landed already. But checking it the optimization was<br>
for fbdev to batch up updates more (because that one doesn't even<br>
try), not direct X usage. So your X should work faster if you use<br>
fbdev as backend (just as an experiment).<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yeah, I used fbdev to test before which got me down this path to look up what's wrong with the modesetting driver. </div><div dir="auto"><br></div><div dir="auto">Fbdev runs flawlessly but then we lose panfrost for other acceleration so it's unfortunately not a silver bullet. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>> Also X should only call this in the blocker handler, not all the time.<br>
><br>
><br>
> It does but fvwm is an example that forces it to be called a lot and it's slow enough to cause significant issues.<br>
><br>
>><br>
>> So yeah we need to make this faster, not break manual update panels.<br>
><br>
><br>
> 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?<br>
<br>
Not impossible, but there's a pile of layers in the way. And generally<br>
frontbuffer rendering doesn't see a lot of love, since aside from<br>
bootloaders and old sckool X window systems without compositors,<br>
they're not really seeing any use. Everything Wayland or composited<br>
desktops is double-buffered and fast.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For fbdev we're also doing the dirty tracking now at a driver level<br>
(using the helpers), unconditionally whether the given hw actually<br>
needs it or not.<br>
<br>
More pragmatic approach would be to throw a kernel thread at this<br>
problem. Will be tricky since we need to make sure that from<br>
userspace's pov nothing breaks, which is always a bit an issue when<br>
making things more asynchronous. Specifically we need to make sure<br>
that userspace doesn't get ahead of the kernel, so might need to<br>
require that we only batch up updates for the same framebuffer object,<br>
but stall when we switch.<br>
<br>
The locking for this will get interesting.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">I haven't done any testing or benchmarking on Wayland so I have no knowledge if this makes any difference there. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">Thanks for the insight and I'm happy to test any solution if something comes up! </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers, Daniel<br>
<br>
> Making a low performance device wait any extra time for no reason doesn't sound like the correct fix either.<br>
><br>
> 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.<br>
><br>
> Thanks.<br>
><br>
><br>
>> -Daniel<br>
>><br>
>> ><br>
>> > --<br>
>> > Toni Spets<br>
>><br>
>> > From 79984ee67c801f552e9eaf4d0cfb62101d1f0f2e Mon Sep 17 00:00:00 2001<br>
>> > From: Toni Spets <<a href="mailto:toni.spets@iki.fi" rel="noreferrer noreferrer" target="_blank">toni.spets@iki.fi</a>><br>
>> > Date: Wed, 3 Feb 2021 21:14:50 +0200<br>
>> > Subject: [PATCH] drm/rockchip: remove atomic helper dirtyfb<br>
>> ><br>
>> > ---<br>
>> >  drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 1 -<br>
>> >  1 file changed, 1 deletion(-)<br>
>> ><br>
>> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c<br>
>> > index 3aa37e177667..2554fd1c8aeb 100644<br>
>> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c<br>
>> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c<br>
>> > @@ -21,7 +21,6 @@<br>
>> >  static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {<br>
>> >       .destroy       = drm_gem_fb_destroy,<br>
>> >       .create_handle = drm_gem_fb_create_handle,<br>
>> > -     .dirty         = drm_atomic_helper_dirtyfb,<br>
>> >  };<br>
>> ><br>
>> >  static struct drm_framebuffer *<br>
>> > --<br>
>> > 2.27.0<br>
>> ><br>
>><br>
>> > _______________________________________________<br>
>> > dri-devel mailing list<br>
>> > <a href="mailto:dri-devel@lists.freedesktop.org" rel="noreferrer noreferrer" target="_blank">dri-devel@lists.freedesktop.org</a><br>
>> > <a href="https://lists.freedesktop.org/mailman/listinfo/dri-devel" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/dri-devel</a><br>
>><br>
>><br>
>> --<br>
>> Daniel Vetter<br>
>> Software Engineer, Intel Corporation<br>
>> <a href="http://blog.ffwll.ch" rel="noreferrer noreferrer noreferrer" target="_blank">http://blog.ffwll.ch</a><br>
<br>
<br>
<br>
-- <br>
Daniel Vetter<br>
Software Engineer, Intel Corporation<br>
<a href="http://blog.ffwll.ch" rel="noreferrer noreferrer noreferrer" target="_blank">http://blog.ffwll.ch</a><br>
</blockquote></div></div></div>