Re: [PATCH v3 0/2] RHEL7 improvements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 3 Mar 2017, at 13:10, Marc-André Lureau <mlureau@xxxxxxxxxx> 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 (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?


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


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

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]