Re: [iGVT-g] Ask for comments of getting guest framebuffer in igvt-g

[Joonas Lahtinen <joonas.lahtinen@linux.intel.com>]

On ti, 2016-03-08 at 09:36 +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > 
> > 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.

Regards, Joonas

> 
> cheers,
>   Gerd
> 
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx