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

Frediano Ziglio fziglio at redhat.com
Fri Mar 3 12:00:54 UTC 2017


> 
> 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)
> 

Fine with it.
Can you do it?

Frediano


> > 
> > 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



More information about the Spice-devel mailing list