|Summary:||Very sluggish graphical performance in qxl/spice guests with spice streaming enabled (default configuration)|
|Product:||[Fedora] Fedora||Reporter:||Mike FABIAN <mfabian>|
|Component:||xorg-x11-drv-qxl||Assignee:||Alon Levy <alevy>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||19||CC:||ahmadsamir3891, airlied, alevy, alexl, awilliam, bugzilla, cfergeau, crobinso, dblechte, eblake, fziglio, hdegoede, jforbes, kparal, marcandre.lureau, mfabian, mruckman, petersen, robatino, sandmann, satellitgo, uril, vg.aetera, xgl-maint|
|Target Milestone:||---||Keywords:||CommonBugs, Reopened|
|Fixed In Version:||xorg-x11-drv-qxl-0.1.1-3.fc19||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-12-21 02:28:39 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Mike FABIAN 2013-10-17 15:06:20 UTC
Created attachment 813386 [details] vnc-fast-spice-slow-comparision.ogv I installed Fedora 20 Beta TC4 in qemu, using: ionice -c 3 qemu-kvm -enable-kvm -global qxl.ram_size=1x1024 -m 2048M -smp 4 -drive file=./Fedora-20-Beta-TC4-x86_64-netinst.iso.qcow2,index=0,media=disk,cache=unsafe -localtime -serial file:/tmp/qemu-Fedora-20-Beta-TC4-x86_64-netinst.iso.qcow2-output.log -name Fedora-20-Beta-TC4-x86_64-netinst.iso.qcow2 -cdrom /local/mfabian/iso/Fedora-20-Beta-TC4/Fedora-20-Beta-TC4-x86_64-netinst.iso -boot c -spice port=6000,disable-ticketing -vga qxl -display vnc=:4 -net nic -net user,hostname=Fedora-20-Beta-TC4-x86_64-netinst.iso.qcow2,hostfwd=tcp::5556-:22 -monitor stdio -usb QEMU 1.6.1 monitor - type 'help' for more information (qemu) Then I watch the guest with spice protocol using remote-viewer spice://localhost:6000 and vnc protocol using: vncviewer :4 (I could also use “remote-viewer vnc://localhost:5904”, this makes no difference as far as this bug report is concerned, it is also fast). Updating the graphics often seems *much* slower when using spice compared to vnc. This is especially easy to notice when scrolling in firefox on a page which has many pictures. The attached video shows “vncviewer :4” on the left side and “remote-viewer spice://localhost:6000” on the right side, both looking at the same guest. In the video, I scroll down in the web page shown by firefox, one can see that the graphics update is quite fast in the left window using vnc but very slow in the right window, using spice.
Comment 1 Jens Petersen 2013-10-18 06:23:41 UTC
Could this be a potential beta blocker?
Comment 2 Chris Murphy 2013-10-20 23:04:52 UTC
Seems both slow and with some nasty artifacting. But what beta or final release criteria is violated by this?
Comment 3 Jens Petersen 2013-10-21 03:43:52 UTC
Seems better with a F20 host. Now I am wondering if this is more of F19 host vm issue? F20 Beta Desktop guests also seem to perform better with 1.5GB ram.
Comment 4 Adam Williamson 2013-11-13 20:01:52 UTC
Discussed at 2013-11-13 blocker review meeting - http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-13/f20-final-blocker-review-1.2013-11-13-17.01.log.txt . Rejected as a blocker: slowness in KVMs is inconvenient but not release blocking, and those at the meeting are not seeing this exact problem.
Comment 5 Dave Airlie 2013-11-13 21:30:22 UTC
please check with the latest xorg-x11-drv-qxl driver that is queued for f20.
Comment 6 Adam Williamson 2013-11-16 01:39:25 UTC
It's not just scrolling in Firefox that's affected by this, I've seen similar sluggishness and horizontal 'stripes' of the display lagging behind the rest during refreshes in other apps too (e.g. gnome-initial-setup). And I can reproduce the same behaviour with an F19 guest (install from F19 live image, so the F19 package set as of release time) on an F20 host, interestingly, but I'm pretty sure it wasn't happening with F19-on-F19 during F19 validation time. Yet Mike reports seeing it with an F20 guest on an F19 host...
Comment 7 Adam Williamson 2013-11-25 20:31:38 UTC
Adjusting the summary, this seems like a more general issue: for me, graphical performance in 20-on-20 GNOME VMs is just very very sluggish, I have the scrolling problem the OP mentions but that's not all. I can actually see what look like JPEG compression artefacts in my clients just performing normal operations like opening a terminal and typing stuff. It's kind of odd.
Comment 8 Adam Williamson 2013-11-25 20:34:49 UTC
proposing as a final FE at least, it's kind of painful testing live images with this slowness.
Comment 9 Adam Williamson 2013-11-25 20:42:22 UTC
To reproduce - at least my version - you just need to have an F20 host, boot an F20 desktop live image on it, and try using it. Just open a browser and browse around or open a terminal and run some stuff, move a few windows, normal stuff. The very sluggish performance is pretty immediately apparent. A test I just did was to open two gnome-terminal windows, run top in one, and drag the other one around while watching the numbers in the other. There's very obvious artifacting on the drag operation - whole sections of the window don't move - and gnome-shell's CPU usage in top quickly jumps way over 100%. I'll have to compare and see if similar bad behaviour exists in KDE...
Comment 10 Adam Williamson 2013-11-25 20:49:17 UTC
OK, it seems to behave pretty well in KDE. Mike, can you confirm this only affects GNOME for you? If so it looks like we're looking at a sudden extreme drop in llvmpipe-on-qxl performance, or something similar.
Comment 11 Adam Williamson 2013-11-25 21:30:37 UTC
Hmmm. I can reproduce the poor performance in an F19 (release-time) guest on an F19 (fully updated) host (and an F19 release-time guest on an F20 host, for that matter). But I'm almost sure it wasn't behaving like this at F19 release time. Do you recall whether you saw it back then, Mike? I wonder if something that's been pushed to F19 stable, not just F20, since F19 release is to blame, here.
Comment 12 Adam Williamson 2013-11-25 21:48:32 UTC
18-on-20 is definitely different. A lot less artifacting. It's still not exactly perfect - if you do the drag-a-terminal-window-around test, it lags appreciably behind the cursor - but there isn't bad artifacting in that test, or in a Firefox scroll-a-pictureful-webpage test, and I never see the 'heavily overcompressed JPEG-alike' artifacting in an F18 guest.
Comment 14 Adam Williamson 2013-11-26 00:19:54 UTC
airlied suggested that I disable Spice streaming mode: <graphics type='spice' autoport='yes'> <streaming mode='off'/> </graphics> in the VM definition. That does indeed make things a huge amount better in all respects. Faster, no artifacting that I can catch, observed CPU usage in the guest when doing the terminal window drag test is much lower.
Comment 15 Fedora Update System 2013-11-26 22:27:16 UTC
xorg-x11-drv-qxl-0.1.1-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/xorg-x11-drv-qxl-0.1.1-3.fc20
Comment 16 Adam Williamson 2013-11-26 22:30:22 UTC
The update improves things massively for me, about as good as disabling streaming.
Comment 17 Mike Ruckman 2013-11-26 22:37:10 UTC
Comment 18 Dennis Gilmore 2013-11-26 22:39:53 UTC
+1 to FE from me. having sluggish guests seems not nice
Comment 19 Adam Williamson 2013-11-26 22:41:41 UTC
acceptedfreezeexception with three votes, thanks.
Comment 20 Fedora Update System 2013-11-27 16:07:27 UTC
Package xorg-x11-drv-qxl-0.1.1-3.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-qxl-0.1.1-3.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-22263/xorg-x11-drv-qxl-0.1.1-3.fc20 then log in and leave karma (feedback).
Comment 21 Fedora Update System 2013-11-29 13:58:50 UTC
xorg-x11-drv-qxl-0.1.1-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Comment 22 Cole Robinson 2013-12-02 19:15:39 UTC
*** Bug 1019020 has been marked as a duplicate of this bug. ***
Comment 23 Adam Williamson 2013-12-13 09:30:38 UTC
I'm re-opening this and re-setting version to 19 as I think we ought to ship the workaround as an update to F19 as well - per my testing (see c#6), it affects F19 guests too.
Comment 24 Fedora Update System 2013-12-17 00:10:27 UTC
xorg-x11-drv-qxl-0.1.1-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/xorg-x11-drv-qxl-0.1.1-3.fc19
Comment 25 Fedora Update System 2013-12-17 19:12:21 UTC
Package xorg-x11-drv-qxl-0.1.1-3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-qxl-0.1.1-3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-23510/xorg-x11-drv-qxl-0.1.1-3.fc19 then log in and leave karma (feedback).
Comment 26 Fedora Update System 2013-12-21 02:28:39 UTC
xorg-x11-drv-qxl-0.1.1-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.