[Spice-devel] [PATCH 00/12] Set of patches for further support of VSync

[Yuri Benditovich]

On Tue, Mar 28, 2017 at 5:14 PM, Frediano Ziglio <fziglio at redhat.com> wrote:

> >
> > The main goal is to reduce time in GDI callback (PresentDisplayOnly) and
> > avoid
> > situation when the processing takes more than 2 seconds causing class
> driver
> > watchdog.
> >
> > 1. We offload sending of drawable commands to separate thread (waiting
> for
> > room in command ring
> >    may take unpredictable time)
> > 2. In case the usage of device memory is high, allocation of bitmap for
> > rectangle to draw
> >    also may take unpredictable time (note that single full screen redraw
> >    requires >3 MB of space)
> >    So, we make drawable objects allocation from GDI callaback fast and
> >    non-forced and in case they
> >    fail we provide alternate allocation from OS heap
> > 3. The thread before send drawable command shall take care on these
> objects
> > that was allocated from
> >    OS heap and allocate them from device memory (now we are not limited
> by
> >    time)
> > 4. We still do not enable VSync automatically, but this can be done for
> > evaluation/testing purpose via
> >    setting in the driver's registry
> >
>
> A big issue of this approach is that it does not entirely solve
> the problem but move it.
>

We can't spend too much time waiting for memory in OS callback.
In our own thread our wait can be as long as we want.


> Instead of waiting for device memory we fallback to system one
> and when we can send commands we copy back to device memory and
> send it increasing system memory usage and memory copies.
>

Yes, that's correct. Our processing in OS callback must be fast and I do
not see how we can
solve it without using host memory and without skipping operation.


> However I cannot see any limitation so potentially we'll fill
> system memory till the guest crash. And if we add a limitation
> potentially this will just move the hang to later.
>

We allocate pageable memory which is much less limited than non-pageable
and typical amount of available pageable memory is > 1G
When working in LAN environment, there is rare cases when we need to
allocate host memory.
With long end-to-end delay under heavy scenarios I did not see huge amount
of outstanding allocation.


> As far as I know we always have available 3 times the amount
> of memory of the maximum frame buffer to in theory plenty of
> space. But trying to see the drawing from the client I can see
> lot of redrawing of the same area again and again so maybe
> this is causing the issues with the memory.
> Maybe we can find a smarter way to solve this memory issue?
>

I would suggest to look for possible improvements later.
I have some ideas but they do not invalidate current solution.


>
> > Yuri Benditovich (12):
> >   qxl-wddm-dod: Prepare system thread for rendering
> >   qxl-wddm-dod: Use rendering offload thread
> >   qxl-wddm-dod: Introduce TimeMeasurement class for timing debugging
> >   qxl-wddm-dod: Debug warning on long wait on event
> >   qxl-wddm-dod: Reduce amount of unnecessary printouts
> >   qxl-wddm-dod: Registry-based control over VSync
> >   qxl-wddm-dod: Set VSync indication period to 200ms
> >   qxl-wddm-dod: Prepare for failure to allocate memory
> >   qxl-wddm-dod: PutBytesAlign supports non-forced allocation
> >   qxl-wddm-dod: Optimize allocation of memory chunks
> >   qxl-wddm-dod: Implement non-forced bitmap allocation
> >   qxl-wddm-dod: Non-forced memory allocations with VSync
> >
> >  qxldod/QxlDod.cpp | 581
> >  +++++++++++++++++++++++++++++++++++++++++++++---------
> >  qxldod/QxlDod.h   |  87 +++++++-
> >  qxldod/driver.cpp |  35 ++++
> >  3 files changed, 606 insertions(+), 97 deletions(-)
> >
>
> Frediano
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20170328/072f92ad/attachment-0001.html>