On Thu, Feb 4, 2021, 18:18 Daniel Vetter <daniel@xxxxxxxx> wrote:
On Thu, Feb 4, 2021 at 5:03 PM Toni Spets <toni.spets@xxxxxx> wrote:
>
>
>
> On Thu, Feb 4, 2021, 17:20 Daniel Vetter <daniel@xxxxxxxx> 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.spets@xxxxxx>
>> > 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@xxxxxxxxxxxxxxxxxxxxx
>> > 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
