From: Gerd Hoffmann <kraxel@redhat.com>
To: Timo Lindfors <timo.lindfors@iki.fi>
Cc: David Airlie <airlied@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Maxime Ripard <mripard@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
LKML <linux-kernel@vger.kernel.org>,
Alex Constantino <dreaming.about.electric.sheep@gmail.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [BUG][v6.9-rc6] Deadlock with: Revert "drm/qxl: simplify qxl_fence_wait"
Date: Tue, 7 May 2024 12:21:50 +0200 [thread overview]
Message-ID: <obume4wdvgxc3zljnelhpwrg2rouae322nak5jy3s4hsruoddd@stoopms6fo2a> (raw)
In-Reply-To: <alpine.DEB.2.20.2405070933070.20162@mail.home>
On Tue, May 07, 2024 at 09:38:56AM GMT, Timo Lindfors wrote:
> On Tue, 7 May 2024, David Airlie wrote:
> > I expec this will reintroduce the other problems that caused this
> > change in the first place, but I think this should at least bring us
> > back to regression equilibrium. I can't recommend anyone use qxl hw
> > over virtio-gpu hw in their VMs, since virtio-gpu is actually hw
> > designed for virt.
Well, qxl was designed for virt too, but almost two decades ago with 2d
acceleration. And alot of complexity, trying to move 2d-accel rendering
from the VM guest to the spice client. That complexity still bites us
today as this issue shows.
With desktop rendering moving to 3d acceleration all that 2d accel stuff
became mostly useless though, so you have the downsides of the
complexity without any upsides.
There have been plans to add 3d-acceleration support to qxl, but they
never took off and with virtio-gpu having taken that role meanwhile the
idea is dead now.
I second the recommendation to avoid qxl.
> I would love to switch to virtio. It works ok for local virtual machines but
> I have many users who are using Linux desktops hosted on a powerful server
> where it is more difficult. With spice and qxl scrolling in a web browser is
> smooth, with spice and virtio it seems like larger parts are getting fully
> redrawn (and resent over network?).
Hmm, I'd expect behavior being quite simliar for stdvga, qxl and
virtio-gpu when running a wayland desktop remotely.
When running on X11 without 3d acceleration it could be that scroll
ops are actually sent as 2d accel blits on qxl, explaining the
difference you are seeing.
> Now that new gnome is going to come with RDP support I'm also
> considering switching to that. Any tips would be appreciated.
Worth trying: use vnc. The qemu vnc server will skip updates when the
network pipeline is full. That throttles the frame rate, but also
reduces the display update latency.
In general the trend seems to be to move to in-guest remote desktop
solutions. Do NOT make VMs a special case with a special solution,
instead handle VMs like bare metal. Commercial solutions exist for a
while, some of them are doing hardware-assisted video encoding to send
the display as video stream to the remote end. gnome+rdp is a new
player here, clearly worth a try.
take care,
Gerd
next prev parent reply other threads:[~2024-05-07 10:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-02 12:16 [BUG][v6.9-rc6] Deadlock with: Revert "drm/qxl: simplify qxl_fence_wait" Steven Rostedt
2024-05-02 12:30 ` Steven Rostedt
2024-05-04 8:39 ` Steven Rostedt
2024-05-06 12:45 ` Maxime Ripard
2024-05-06 20:28 ` Linus Torvalds
2024-05-07 5:54 ` David Airlie
2024-05-07 6:38 ` Timo Lindfors
2024-05-07 10:21 ` Gerd Hoffmann [this message]
2024-05-07 15:46 ` Timo Lindfors
2024-05-08 9:56 ` Gerd Hoffmann
2024-05-07 9:03 ` Steven Rostedt
2024-05-08 12:42 ` Anders Blomdell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=obume4wdvgxc3zljnelhpwrg2rouae322nak5jy3s4hsruoddd@stoopms6fo2a \
--to=kraxel@redhat.com \
--cc=airlied@redhat.com \
--cc=daniel@ffwll.ch \
--cc=dreaming.about.electric.sheep@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=rostedt@goodmis.org \
--cc=timo.lindfors@iki.fi \
--cc=torvalds@linux-foundation.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.