[Intel-gfx] [iGVT-g] Ask for comments of getting guest framebuffer in igvt-g

[Tian, Kevin]

> From: Zhiyuan Lv
> Sent: Tuesday, March 08, 2016 9:26 AM
> 
> > > The igvt device model is responsible for injecting vblank interrupts to VMs
> > > for i915 running inside. Currently we have a timer for the regular vblank
> > > injection. So if needed, host i915 can notify gvt device model to delay
> > > vblank for a VM, hence delay the flip from VM's point of view. BTW, the idea
> > > of delay is not in current gvt code. We are not sure whether it is a must to
> > > have and whether it is the best way. Just feel that it is doable. Thanks!
> > >
> >
> > The timer best follows the "real hardware" imitation scenario, so it
> > should be good. Would it be an option to triple-buffer, keeping a copy
> > of the frame intact which the DOM0 is drawing? Or is that too harsh on
> > memory requirements.
> >
> > That would avoid tearing, but also let the guest freely update at
> > constant rate. From DOM0, the compositor or whatever application
> > consumes the frames, would just observe frame skipping instead of
> > tearing.
> 
> Thanks for the idea! Keeping a copy could avoid the tearing
> completely. Following that approach, we may not need the special
> gvtbuffer gem object. We can introduce an IOCTL to copy a VM's
> framebuffer to a given normal gem object, then make sure that during
> the copy, guest driver in VM will not modify the fb.
> 
> The only concern here is the performance impact, since there have to
> be memory copy for each frame. I do not have data in hand, but guess
> that might be quite significant. Thanks!
> 

memory copy is very slow (especially when aperture is mapped as WC
which means uncatchable). If necessary we should use GPU to blit the
content however it then means you still need a gem object. :-)

btw I don't think this vblank issue would be very significant. The main
targeted usage of GVT-g is for server virtualization/cloud, where 
a remoting protocol is required for customer to see the content through
network. My feeling is that tearing should be well considered already by
those remoting protocols, regardless of how vblank is virtualized.

Thanks
Kevin