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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/spice-devel > _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel