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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
