[Intel-gfx] [iGVT-g] Ask for comments of getting guest framebuffer in igvt-g
joonas.lahtinen at linux.intel.com
Thu Mar 10 10:00:17 UTC 2016
On ti, 2016-03-08 at 09:36 +0100, Gerd Hoffmann wrote:
> > 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.
There is also the use scenario of locally scanning out the buffers with
real hardware, the DOM0 working as a kind of KVM switch.
> The plan for that is to let the gpu video encoder process the guest
> framebuffer. So the video encoder still being busy processing the
> buffer while the guest already started updating it can certainly lead to
> visible tearing.
> I think using vblank to signal the guest when the host is done
> processing the framebuffer makes sense. It'll simply throttle the guest
> in case the host is too busy to keep up.
This was my initial suggestion, but I could see this exposing plenty of
behavior on the guest system that is not covered by regular testing.
> Storing the guest framebuffer via blit somewhere else, just to allow the
> guest render at full frame rate even if the host isn't able to process
> the frames fast enough looks pointless to me. We are simply wasting gpu
> cycles then.
This just happens to be the most non-invasive way of doing it, where
guest will behave much like on real hardware.
I'm not taking a stance for triple buffering, but I think it's
important that we do not consider just a single use-case and rule other
options out. Especially if the timer system is already been tested some
and could serve both scenarios.
Open Source Technology Center
More information about the Intel-gfx