[Spice-devel] [PATCH RFC 00/12] Remote Virgl support

[Frediano Ziglio]

> 
> Hi,
> 
> > > Hmm.  The guest will not give us 2-3 frames though.  We'll have either
> > > one or two, depending on whenever the guest uses page-flips or not.  So
> > > implementing a buffering scheme as outlined above requires us to copy
> > > (or let the gpu copy) the frames.
> 
> > Probably 2 are enough, 1 I have to think about it, there may be some
> > possible timing problems. What happens if single frame processing
> > take too much? Does guest slow down?
> 
> Oops, I think I have to correct myself.  You get one frame, period.
> Yes, the guest will slow down.  Right now we stop all virgl rendering
> until spice signals it is done via QXL_COOKIE_TYPE_GL_DRAW_DONE, to make
> sure the user will not see half-rendered frames.
> 
> Without page-flipping this is pretty much the only thing we can do.
> 
> With page-flipping we can parallelize things a bit: The guest can render
> into one frame while spice process the other one.  It isn't implemented
> today though[1].  Implementing it will not give additional frames for
> queuing, we will get less guest throttling instead.
> 
> cheers,
>   Gerd
> 
> [1] we have to block virgl rendering to current scanout only,
>     instead of blocking all virgl rendering.
> 
> 

Mumble. I was thinking this situation:
1- Clients are disconnected;
2- Screen updates normally sending gl_scanout/gl_draw to spice-server;
3- Updates stops;
4- Client connect.

At step 4 we need to send something to the client which means we need the
last scanout. But the last scanout is sent even minutes before and at this
time we should have replied to Qemu but doing so we allow guest to change the
texture so when we need it we are not sure it'll contain the right data.

In the physical world the screen have always a frame buffer attached
so the last texture is always valid.

Frediano