[Spice-devel] qxl and page flip
Dave Airlie
airlied at gmail.com
Fri Oct 6 03:24:43 UTC 2017
On 4 October 2017 at 21:38, Gerd Hoffmann <kraxel at redhat.com> wrote:
> Hi,
>
>> > So, the options I see are:
>> >
>> > (1) Declare qxl deprecated, promote virtio-vga instead.
>> >
>> > (2) Pimp the qxl hardware, add page-flip support. Requires
>> > changes
>> > in spice-server (due to lazy rendering), qemu qxl emulation
>> > and
>> > guest kernel driver. Should be transparent to spice-client
>> > and
>> > guest userspace (aka xorg qxl driver).
>
>> I don't think that supporting page flipping in QXL would be hard.
>
> Yes, it shouldn't be difficult.
>
> But still requires new versions on both guest and host side.
> And these new versions will have virtio-vga support too.
>
> Also note that wayland will not use any qxl 2d accel operations. Same
> is true for any opengl compositors like gnome-shell when running on
> xorg. So performance-wise it should not make a big difference whenever
> you are using qxl or virtio-vga (without virgl), it's all llvmpipe
> software opengl rendering in both cases.
>
> So, is it worth updating qxl?
> Or should we focus on virtio-vga instead?
I think we should try and refocus on virtio-vga for Linux guests, I don't think
we currently gain anything majorly useful from qxl acceleration under composited
environments, though if we did plumb through more things maybe we could get
the video encoding youtube use case working better again.
The other option is we revert atomic modesetting from upstream qxl until the hw
is upgraded to it, and we use the atomic path only on the newer hardware.
I'd really like to see some commitment to fixing qxl if we do decide to do that.
Dave.
>
>> Would just requires to support calling create surface having a
>> surface and detecting that only the pointer changes.
>
> Either that, or an explicit QXL_SURF_FLAG_PAGEFLIP instead of the
> detection.
>
> But when touching the qxl virtual virtual hardware anyway we might
> consider to deprecate the concept of a "primary surface" altogether and
> just allow mapping normal surfaces to output heads instead. Which
> would be alot closer to how physical hardware works today and should be
> more future-proof. Of course that would be a bigger change and
> probably requires spice-protocol changes too.
>
> cheers,
> Gerd
>
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
More information about the Spice-devel
mailing list