> On 6 Mar 2017, at 11:42, Frediano Ziglio <fzig...@redhat.com> wrote: > > On 3 Mar 2017, at 13:10, Marc-André Lureau <mlur...@redhat.com > <mailto:mlur...@redhat.com>> wrote: > > Hi > > ----- Original Message ----- > > 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 > <https://www.youtube.com/watch?v=OarV6zUmUdg> (before) > - https://www.youtube.com/watch?v=5fTdCCbFeCg > <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=1158029>; > - https://bugzilla.redhat.com/show_bug.cgi?id=1294564 > <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 > <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? > > > I may eventually do it, but it's not in my priorities. > > The last update from me was "[PATCHv2 0/9] drisw/glx: use XShm if possible" > (6/15/15). > > Adam Jackson was supposed to review/take it. I don't know if anything > happened since. > > Ajax, any update? could you look at it? I see the bug is assigned to Dave > (rhbz#1030024) > > Anyone willing to take it? > > Willing I am. Able I don’t know ;-) If I’m stumped, I know who to call for > help. > > Christophe > Would be great to have this fixed instead of a workaround! > On the other way the only thing we could do is updating the patch, testing > and pushing Mesa > to merge it. > Could we actually just accept the patch downstream, at least for 7.4 ? > > Posted a message in https://bugzilla.redhat.com/show_bug.cgi?id=1030024 > <https://bugzilla.redhat.com/show_bug.cgi?id=1030024> to ask > for some commitment. Seems that the bug was stuck since an year.
I adjusted the patch for the then-current version of mesa. See https://github.com/c3d/mesa/commit/6709e8c3bd8af5df9f748ee3449598aa1787fe51. Updated rhbz1030024. Christophe > > Frediano > > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org <mailto:Spice-devel@lists.freedesktop.org> > https://lists.freedesktop.org/mailman/listinfo/spice-devel > <https://lists.freedesktop.org/mailman/listinfo/spice-devel>
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
