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