On 28/07/15 17:50, Jeremy White wrote:
Frediano Ziglio indicated he was hoping to do some work on XSpice, and
asked me to share my todo list or thoughts on ways it could improve.
Made me feel like a kid in a candy store <grin>.
We had an irc chat; I thought I'd restate some of the items and share
them for posterity.
A brief history: XSpice includes spiceqxl_drv.so; an Xorg driver, and
XSpice, a script that helps launch X as a virtual frame buffer server
that speaks Spice.
It shares code and DNA with the qxl_drv.so used inside a qemu vm/Xorg
system to provide better Spice integration.
It was created by Alon Levy initially. I and a few others have spent
time improving it so that it has near feature parity with qemu (e.g.
audio, smartcard, agent support, etc).
It uses the same interface with the spice server that the qxl_drv uses,
which is less than ideal. That is, it pretends to have a VGA rom and an
mmapped region of memory, and pushes instructions in through a ring
buffer. Frediano rightly deduced that improving that interface would be
a good starting point for refactoring/improving it.
To sum up the spice usage is something like
qxl <-> qemu <-> spice-server <-> client
while Xspice driver (spiceqxl) is something like
spiceqxl <-> spice-server <-> client
so basically qxl+qemu == spiceqxl however the implementation is too much
coupled with Qemu. For instance there is an I/O layer emulation (which
I'm removing right now!), ram/rom emulation, the rings are not optimized
for thread communications and still using copy to/from some shared
memory and memory are still managed by a separate pool (malloc/free
could be used instead).
It is still somewhat awkward to use; the XSpice script makes it easier,
but it would be really nice to have a bit of glue to connect it to gdm
via xdmcp, and even more glue to make the spice-html5 client connect
automatically. For a while, gdm was broken wrt xdmcp; I believe those
bugs are now all fixed, so I hope to return to look at that and make a
more polished experience in Fedora rawhide.
A nice feature to add, which I hope to get to someday, is to implement a
parallel to x11vnc. That should enable session shadowing, or access to
your own desktop.
One of the features it has that I think is compelling, which I keep
meaning to make a stronger case for, is the 'Deferred Frames Per Second'
mode, or essentially, a render and send approach. We render into our
frame buffer, and then periodically (at the configured fps) we send the
changed regions over the wire. This is the approach used by vnc.
I realize this is heresy, but I did a fair amount of bandwidth and cpu
usage analysis, and with typical Linux desktop usages, the dfps mode was
dramatically better. Further, in some cases (*cough* fluxbox *cough*),
'regular' Spice is virtually unusable; the dfps approach was the only
choice. I have to work much harder to find a use case where dfps is
worse than the 'regular' protocol. I had an experimental patch that
enabled dfps for qemu/qxl, but it was buggy, and I never found the time
to fix it up and try to make the argument.
But with dfps on, I'm able to get slightly better bandwidth usage than
vnc, and my (arguably biased) sense is that the user experience is
better as well, at least for typical Linux desktop work loads.
</heresy>
Well, spice has some bad corner cases. Actually it lack a continuous
bandwidth analysis and there are some implementation of the protocol
that make latency affect badly on some conditions.
Just an example of extreme case think about if interface was designed
pixel by pixel it could happen that each pixel is transformed into a 1x1
image drawing (there is no "PutPixel" call on the protocol).
spice should try better to balance CPU usage and bandwidth also
considering that a lot of small drawing tend to cost quite lot of CPU too.
Well... this adaptive protocol would solve lot of problems possibly
making a full DFPS useless.
Another todo is profiling; XSpice cpu usage, particularly for the spice
server, is substantially higher than that of vnc. I'm hoping that as we
refactor some of the red_*, it may be possible to carve out simpler code
paths for XSpice (or at least to profile and understand the pain).
Do you have some profiling data?
Just trying to be rigorous: the Xorg driver bits were really done as a
proof of concept. I've tried to clean them up, but some rigorous
thought around making them 'correct' would be helpful. Notably, it
would be nice to eliminate the whole set of errors generated at Xorg
start time about the keyboard and mouse (although that work may be in
Xorg, not XSpice).
And, of course, we share the pain around 3D desktop effects that the
qxl_drv has. Hopefully the solution imagined for that will work for us
as well.
In a similar vein, there is a proliferation of xorg.conf options; it
would be nice to reduce or eliminate those.
Eliminating the memory allocation emulation would probably remove some
of them.
Finally, I haven't done any thinking about fun things like Wayland.
That could be a useful task as well.
Never worked with Wayland. But probably 3D would be even more fun. But
looks like a much bigger project. For now let's focus on making Xspice
driver into a better shape!
Cheers,
Jeremy
Frediano
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel