[Spice-devel] [PATCH v3 0/2] RHEL7 improvements
Christophe de Dinechin
cdupontd at redhat.com
Wed Mar 22 10:35:06 UTC 2017
> On 6 Mar 2017, at 11:42, Frediano Ziglio <fziglio at redhat.com> wrote:
>
> On 3 Mar 2017, at 13:10, Marc-André Lureau <mlureau at redhat.com <mailto:mlureau at 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 at lists.freedesktop.org <mailto:Spice-devel at lists.freedesktop.org>
> https://lists.freedesktop.org/mailman/listinfo/spice-devel <https://lists.freedesktop.org/mailman/listinfo/spice-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20170322/9275c9c0/attachment-0001.html>
More information about the Spice-devel
mailing list