QXL/spice driver

[kstabel]

Hi,

Haiku is very well behaved as a guest on KVM, but the one thing lacking at this time is good video acceleration. The draw performance using the VESA driver is quite poor.

Is there anything planned with regards to this?

[waddlesplash]

What do you mean that the draw performance is poor? Do you have any statistics?

[kstabel]

Replying to waddlesplash:

What do you mean that the draw performance is poor? Do you have any statistics?

There is quite a bit of tearing when moving windows, video playback is pretty choppy, even scrolling in webpositive is choppy.

Drawing also uses quite a bit of cpu cycles (no real acceleration).

[waddlesplash]

Tearing is basically invisible here, and video playback is not that choppy. Are you not using KVM or another hypervisor?

[kstabel]

Replying to waddlesplash:

Tearing is basically invisible here, and video playback is not that choppy. Are you not using KVM or another hypervisor?

I'm using KVM with QXL/spice as a video device. I've experienced the same results/effects on three different machines.

[tqh]

This looks more like a problem with framebuffer performance in Spice. As we don't use gfx acceleration in Vesa you need a fast framebuffer, and as Spice seems to built for remote clients, this is probably the least useful KVM driver for Haiku.

[kstabel]

Replying to tqh:

This looks more like a problem with framebuffer performance in Spice. As we don't use gfx acceleration in Vesa you need a fast framebuffer, and as Spice seems to built for remote clients, this is probably the least useful KVM driver for Haiku.

Spice is the default protocol, and QXL the default device for KVM vms in virt-manager, gnome-boxes, ovirt, etc ... Performance is fine locally, or remotely with linux, windows, etc. Can even play 1080p video over the network from my ovirt environment with sound. Locally, the performance is indistinguishable from regular hardware.

That being said, i've tried vmvga, cirrus, etc with KVM. They all suffer the same performance issues. As you said, no acceleration. A QXL accelerant would be very nice, but i suspect that would be a lot of work.

[tqh]

As I do all my development with KVM and don't see the issues you are talking about I wonder what is your hw/setup. Tearing you will see because there is no vertical retrace syncing possible without some hw acceleration. Lagging on the other hand should not be a problem.

To answer your other question, gfx acceleration is something we want, but gfx hw is very complicated and gfx manufacturers are very unhelpful, so it is very hard to do this without paid developers, signed NDA's and support from the manufacturer. Hint: If other vendors had something like AtomBios and helped support its usage like AMD we probably would be much further along.

[kstabel]

Replying to tqh:

As I do all my development with KVM and don't see the issues you are talking about I wonder what is your hw/setup. Tearing you will see because there is no vertical retrace syncing possible without some hw acceleration. Lagging on the other hand should not be a problem.

To answer your other question, gfx acceleration is something we want, but gfx hw is very complicated and gfx manufacturers are very unhelpful, so it is very hard to do this without paid developers, signed NDA's and support from the manufacturer. Hint: If other vendors had something like AtomBios and helped support its usage like AMD we probably would be much further along.

I've ran it on KVM on a dual xeon 56xx or other (my ovirt env), a ryzen machine, a laptop with an i7 8550 and another laptop with an older i7 (fourth gen).

The tearing is no big deal, but just unfortunate. The lagging, yes, it happens when scrolling through a webpage on webpositive, or for example having the terminal full screen and scrolling through that, etc. I get it, no hw acceleration, that's what i'm saying as well. QXL acceleration would be nice.

As for your point on hardware support, yes, i fully understand and agree. However, QXL is a paravirtualized device, for which the spec is just published in the open (Open source).

It's not a must-have, but it would make haiku run pretty nicely on KVM, which is a mainstream virtualization platform on linux. Dare i even say the preferred and nicest one. It would give a lot of people a much nicer experience, that's all i'm saying.

Just an idea.

[tqh]

If it isthe browser and terminal scrolling then it is more likely to be the scrolling in these. Webpositive is still under heavy development, so it is not comparable to state of the art browsers.

[kstabel]

Replying to tqh:

If it isthe browser and terminal scrolling then it is more likely to be the scrolling in these. Webpositive is still under heavy development, so it is not comparable to state of the art browsers.

Hi, i don't experience this on actual hardware, so i don't think so, but that's fine. This was just a suggestion. If you feel like this would be too much work at this stage, then no worries.

[johnsonjh]

I must agree that performance of QXL is very poor here (on a very fast system, an Intel Xeon Gold 6246R at 4.1GHz).

You can compare Haiku with SPICE vs. VNC to see the difference in overall snappiness very easily - no need for virt-manager or anything.

• For SPICE, just put whatever password you want to set in haikupass.txt and start QEMU with something like:

  qemu-system-x86_64                                                          \
      -usbdevice tablet                                                       \
      -smp 12                                                                 \
      -m 2G                                                                   \
      -net user,hostfwd=tcp::25723-:22                                        \
      -net nic,model=virtio-net-pci                                           \
      -drive file=haiku64.raw,format=raw,id=disk0,if=none                     \
      -device virtio-blk-pci,drive=disk0                                      \
      -boot menu=on                                                           \
      -object secret,id=haikupass,file=haikupass.txt                          \
      -spice port=5900,disable-ticketing,password-secret=haikupass            \
      -device virtio-serial -chardev spicevmc,id=vdagent,debug=0,name=vdagent \
      -device virtserialport,chardev=vdagent,name=com.redhat.spice.0          \
      -vga qxl                                                                \
      -enable-kvm                                                             \
      -cpu host,host-phys-bits                                                \
      -monitor stdio
  

• For non-SPICE with VNC, you remove the four lines starting with -object ... and change to vmware for the video type, and enable the VNC server. Once it starts up, use the command change vnc password to set the password.

  qemu-system-x86_64                                                          \
      -usbdevice tablet                                                       \
      -smp 12                                                                 \
      -m 2G                                                                   \
      -net user,hostfwd=tcp::25723-:22                                        \
      -net nic,model=virtio-net-pci                                           \
      -drive file=haiku64.raw,format=raw,id=disk0,if=none                     \
      -device virtio-blk-pci,drive=disk0                                      \
      -boot menu=on                                                           \
      -vnc 127.0.0.1:3,password                                               \
      -vga vmware                                                             \
      -enable-kvm                                                             \
      -cpu host,host-phys-bits                                                \
      -monitor stdio
  

Using QXL in VESA mode with SPICE, you get a lot of tearing and generally much worse performance than using the VMware video device via VNC. I've used various SPICE clients (Remote Viewer, GNOME Boxes, Remmina, flexVDI Client, Virt-Viewer), and they all perform the same.

[johnsonjh]

Besides nearly native video performance, there are other advantages to proper SPICE support via QXL, mostly the ability for the guest to resize automatically to the viewer with any arbitrary resolution and not require setting a standard size, sharing the clipboard sanely, etc.

[tqh]

I am not suggesting this as an alternate solution but can you compare with

-device virtio-vga,xres=1920,yres=1080,edid=on

Just to see how it behaves.

(No need yo use xres yres and edid attrs, I just show them so people know about them.)