[Spice-devel] [RFC 2/2] add shared memory display channel support

[Alon Levy]

> 
> 
> ----- Mensaje original -----
> > Hi,
> > 
> > On 08/13/2013 08:33 PM, Alon Levy wrote:
> > > The new protocol is an extension optionally supported by the client if
> > > setting this capability bit.
> > >
> > > It includes 4 new messages, 3 are new messages (SHM_OFFER, SHM_REPLY,
> > > SHM_DAMAGE) and one replaces an existing message (SURFACE_CREATE_SHM
> > > replaces
> > > SURFACE_CREATE), plus a capability bit that both server and client
> > > advertise
> > > (SPICE_DISPLAY_CAP_SHARED_MEMORY).
> > >
> > > If the server sees the client capability, it will send
> > > MSG_DISPLAY_SHM_OFFER right after the display channel handshake.
> > >
> > > client replies with MSGC_DISPLAY_SHM_REPLY
> > >   - accepted = 0
> > >    - nothing changes, return to normal behavior
> > >   - accepted = 1
> > >    - shared memory behavior commences as described below.
> > >
> > > In shared memory mode:
> > > 1. every message read from the qxl device (via the qxl interface
> > > interface_get_command) is:
> > > 1.1 immediately rendered into the framebuffer
> > >      * since the framebuffer is a shared memory segment, the client can
> > >      immediately use it.
> > 
> > So any drawing will cause rendering? IE the trouble some apps the codewaver
> > guys were trying to
> > deal with which draw things 1 pixel at a time will cause 1000-s of renders
> > /
> > second ?
> > 
> > Not sure if this is a good idea, we should probably do some batching here,
> > or
> > simply render
> > X times / second (skipping rendering when there is nothing to render).
> 
> Isn't that what we are already doing? So shouldn't it be addressed
> separately?

No, we don't do that. We drop operations in the pipe if a new operation comes along - so basically we only drop operations if the network is slow.

DFPS is in the X driver, not in the X sever.

It can be done both in local and remote modes (I think that's a better distinction then with shared / without shared memory), with different collection (batching) times.

> 
> From client side pov, gtk/gtk3 is syncing redrawing with a paint clock,
> hopefully already.
> 
> > Anyways as Christophe said, benchmarks would be good, those will hopefully
> > also help to determine
> > what is the best thing to do here.

Benchmarks so far:
video playback is slightly faster (3% +-1%).
PerformanceTest 8.0 is worse - both in results and in cpu (taking remote-viewer and qemu together).

My methodology is messy - looking at top while running the tests. For video playback it was fairly consistent, for PerformanceTest less so.

> > 
> > Regards,
> > 
> > Hans
> > _______________________________________________
> > Spice-devel mailing list
> > Spice-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> > 
>