[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ibl7jsqhbdga64nasmrruh3t2oa7rxqmwxywe6wtdfsqrliyue@tbgmm6uvxsqi>
Date: Wed, 8 May 2024 11:56:46 +0200
From: Gerd Hoffmann <kraxel@...hat.com>
To: Timo Lindfors <timo.lindfors@....fi>
Cc: David Airlie <airlied@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>, Maxime Ripard <mripard@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>, LKML <linux-kernel@...r.kernel.org>,
Alex Constantino <dreaming.about.electric.sheep@...il.com>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Thomas Zimmermann <tzimmermann@...e.de>, Daniel Vetter <daniel@...ll.ch>
Subject: Re: [BUG][v6.9-rc6] Deadlock with: Revert "drm/qxl: simplify
qxl_fence_wait"
On Tue, May 07, 2024 at 06:46:41PM GMT, Timo Lindfors wrote:
> The qxl + spice + firefox combination scrolls smoothly even if I force
> firefox to use wayland.
scrolling sending 2d accel bitblits works only when running the xorg
xserver with the qxl driver. xwayland wouldn't do that. So that
doesn't explain the performance difference.
> I suppose I could write a more synthetic test if it would be useful?
Well, don't work on qemu graphics any more. So I can't sink much time
into this, and my memories on details are starting to fade ...
> With systemtap I can trace what happens during a single scroll event.
Had a brief look at the driver source code. One possibly important
difference is damage tracking.
qxl seems to send updates for the list of damaged rectangle to the host
(see qxl_draw_dirty_fb).
virtio-gpu goes call drm_atomic_helper_damage_merged() to get a single
rectangle covering all regions which need updating and works with that.
Which could very well explain the performance difference. If you want
dig deeper I'd suggest to start there.
HTH & take care,
Gerd
Powered by blists - more mailing lists