[Spice-devel] RFC: Integrating Virgil and Spice

[Marc-André Lureau]

----- Original Message -----
> 
> 
> ----- Original Message -----
> > On Thu, Oct 10, 2013 at 10:50 PM, Marc-André Lureau <mlureau at redhat.com>
> > wrote:
> > >
> > >
> > > ----- Original Message -----
> > >> Hi,
> > >>
> > >> On 10/10/2013 01:25 PM, Gerd Hoffmann wrote:
> > >> >    Hi,
> > >> >
> > >> > Nice summary.
> > >> >
> > >> >> 3) Virgil will render using the host gpu, using EGL to talk to
> > >> >> a drm render node. For non local displays the rendered contents
> > >> >> will be read back from the gpu and then passed as a pixmap to the
> > >> >> ui to transport over the network
> > >> >
> > >> > Interesting in this context:  What is the status of 3d support for
> > >> > qxl/spice?
> > >>
> > >> Non existent AFAIK
> > >>
> > >> > Is it be possible to transform virgil 3d ops into spice 3d
> > >> > ops, so you could offload the rendering to spice-client?  Does it make
> > >> > sense to try?  Or would the transfer of the data needed to render more
> > >> > expensive than transferring the rendered screen?
> > >>
> > >> AFAIK, people more knowledgable people then me on 3d (ie Keith Packard)
> > >> all seem to agree on that transfering the commands to render would be
> > >> more expensive. IOW adding 3d support to Spice would be not really
> > >> useful.
> > >
> > > afaik, opengl has been designed originally with remote rendering in mind.
> > >
> > 
> > OpenGL 1.0 maybe nobody has made any accommodation to remote rendering
> > in years, they haven't defined GLX protocol for new extensions in
> > probably 8-10 years,
> > 
> > The thing is 3D rendering is high bandwidth for anything non-trivial,
> > the amount of data apps move to GPUs is huge for most things.
> 
> Most opengl applications, but perhaps that's not so true for desktop apps in
> general (including aero etc), as you noted for gnome-shell, which is more
> animated than most applications that just want simple smooth transitions. I
> am not looking at remote gaming or 3d benchmark.
> 
> Even when a lot of data moves to GPU, I wonder how much can actually be
> cached (ie how much is generated on CPU).
>  
> > > I am no opengl expert, but it probably very much depends on the kind of
> > > application (Alon reported us about Android apps remoting being fine).
> > > Wouldn't glx gears be fine too? ;) I think the upcost is pretty big in
> > > general, because of upload of textures and data arrays which are not very
> > > well compressed in raw protocol. Probably a remote protocol, like spice,
> > > could help compress those (and cache on disk!). Then result can be read
> > > back in some applications, but that is not always the case (even
> > > rendering
> > > to texture and composition could be done remotely). Usage of readback is
> > > discouraged in general. Imho, it could be worth some experiments. But
> > > current local only approach is necessary anyway, and the server rendering
> > > approach could be complementary too.
> > 
> > There are numerous massive problems with remote rendering the android
> > remoting guys don't solve because they either don't need to or they
> > are too hard, but for a desktop you'd have to. I'll enumerate them for
> > posterity :-) Also your GL knowledge is a bit out of date :-P
> > 
> > 1) readback - spice currently doesn't do remote readback it always
> > does pixman rendering locally when the client reads something back,
> > now GL isn't pixel perfect and if we have different rendering hw or sw
> > rendering on the host and the client then we'd be giving back results
> > that weren't entirely accurate. Now do we just readback from the
> > client then? probably going to suck. Now things like gnome-shell use a
> > technique called picking on mouse movement and clicks, every mouse
> > movement can cause a readback so it know what object is under the
> > mouse, can you say latency enough?
> 
> This is already in opengl 1.0 iirc (so probably with remoting in mind ;), and
> I don't think latency for picking matters so much in remote environment
> (even then, when there is a mouse click/event on client side, we could
> already gather some picking information perhaps, to avoid round trip), I was
> also imagining the double rendering that you mentionned.

If there is enough interest, we could measure this running a VirtualBox Win7+some desktop applications with aero, run apitrace under it (that should be possible), and gather some statistics (with some compression tools etc). That could give a rough estimate of bandwidth.