[Spice-devel] [PATCH v3 0/2] RHEL7 improvements

[Marc-André Lureau]

Hi

----- Original Message -----
> These 2 patches attempt to join images split by RHEL7 graphic
> stack (Mesa) decreasing commands handled by spice-server.
> 
> You can see the difference between the 2 video:
> - https://www.youtube.com/watch?v=OarV6zUmUdg (before)
> - https://www.youtube.com/watch?v=5fTdCCbFeCg (after)
> These video are realized with some additional changes:
> - the statistics from the terminal have some additional
>   "out_messages" counters. These counters show the messages
>   sent to the client(s). These changes are part of my "stat"
>   branch (partially sent couple of days ago);
> - the replay utility, as you can see, was changed to replay
>   using the real time to allow the video code (which is dependent
>   on timing) to work correctly. The patch is currently not in
>   a good shape (enough to be sent);
> - the client utility was changed to remove the delay due to
>   the lip sync. The glitches (present mostly before these patches)
>   are much reduced.
> 
> Note the number of commands sent to the client reduced from 6097
> to 2016 (current year, just a coincidence).
> The network traffic reduced from 72M to 56M. This is due to the fact
> that having a single stream (as you can see VP8 codec was used) the
> compression on the stream is better.
> 
> These patches fix:
> - https://bugzilla.redhat.com/show_bug.cgi?id=1158029;
> - https://bugzilla.redhat.com/show_bug.cgi?id=1294564 (probably).
> 
> In some experiments with the modified replay utility I got
> some additional artifacts respect to the RFC version. This is mainly
> due to the way RedWorker handle commands from graphic driver and the
> way the timeout was handled. In the previous version before checking
> for joining timeout the graphic command queue were always checked
> while with this last series is possible that the timeout trigger
> before checking for new command. This however seems to happen mainly
> to me as the replay utility introduce some delay.

How much extra CPU usage does this take? in non-degenerate case and degenerated case.

I would suggest to fix the root cause: that X splits and copy large region update.

The solution I proposed: https://lists.freedesktop.org/archives/mesa-dev/2015-June/085860.html

Not only it doesn't require extra work on Spice side, but it also improves guest CPU usage by avoiding large memcpy (fullscreen video can be very heavy)

> 
> Changes since v2:
> - lot of style updates (booleans, line split, comments);
> - added many comments;
> - remove a small possible leak (pending drawable);
> - increase a bit timeout to decrease possibility of
>   mis-detection of joinable commands;
> - I kept still 2 commits but I plan to merge them
>   (was suggested).
> 
> Changes since RFC:
> - moved code to DisplayChannel;
> - define a constant for timeout.
> 
> Future possible optimization: not waiting to join if the joined
> command end at the screen bottom or if the last command contain
> a small image (Mesa split at about 64K pixel, 256Kb).
> 
> Frediano Ziglio (2):
>   display-channel: Join drawables to improve rhel7 behaviour
>   display-channel: Handle timeout for joining drawables
> 
>  server/display-channel-private.h |   9 +-
>  server/display-channel.c         | 236 +++++++++++++++++++++++++++++++-
>  server/red-parse-qxl.h           |   1 +-
>  server/red-worker.c              |  14 +-
>  4 files changed, 253 insertions(+), 7 deletions(-)
> 
> base-commit: 5ba0bc6663da2bd0e4c1e23821931426d808c17d
> --
> git-series 0.9.1
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
>