[Mesa-dev] [PATCH] gbm/drm: Pick the oldest available buffer in get_back_bo

[Daniel Stone]

Hi,  
  

  
On Nov 10 2016, at 2:09 pm, Pekka Paalanen <ppaalanen at gmail.com> wrote:  

> On Wed, 9 Nov 2016 14:57:22 -0600  
Derek Foreman <derekf at osg.samsung.com> wrote:

>

> > We find the oldest backbuffer we can, on the grounds that clients are  
> only going to keep a fixed history queue, so this gives them the  
> greatest chance of being able to use that queue via making sure  
> the age is ~always less than the depth of the swapchain

>

> right, that is one side of the story.  

>

> On the other side, damage accumulates frame by frame. When you always  
pick the oldest free buffer, you also maximize the accumulated damage  
and need to repaint more than if you picked the youngest free buffer.

>

> Furthermore, if you normally can do with cycling just two buffers, and  
a hickup causes you to allocate up to four buffers and afterwards you  
come back to the normal steady flow, you are now always cycling through  
all the four buffers and repainting damage for age=4 instead of age=2.

  
This would be a separate problem; the queue depth should really not be any
longer than need be. If there is a case where it ends up longer (say when a
surface switches from direct scanout to GPU composition), then Mesa should be
realising this and trimming the queue. Other stacks do this.  
  

> If one was always picking the youngest free buffer, we could even have  
heuristics to destroy buffers that have not been used for N swaps to  
release some memory.

  
That is not strictly dependent on picking the youngest buffer; it could/should
be done regardless.  
  

> There is a trade-off between repainting a little more than necessary in  
the normal case to mitigate the impact on hickups and making the normal  
case optimized while hickups cause a heavy hit (full repaint plus  
possibly even allocating a new buffer). However, in a proper compositor  
I fail to see how such hickups would even occur - so you wouldn't need  
to mitigate hickups but also using the oldest would not be any worse  
since you never allocate extra buffers.

  
Repainting more than necessary will only occur when the damage area is
changing literally frame-by-frame. This is kind of an odd case, since it means
that your eyes will have to be retargeting every 16ms.  
  

> It would be nice to see more rationale in the commit message about why  
picking the oldest is better than picking the youngest buffer. Age  
greater than the length of the swapchain is only a trigger for full  
repaint, just like a freshly allocated buffer is, except you skip the  
cost of allocating.

>

> My counter-proposal is probably worse, but I'd like to see an  
explanation because it's not obvious.

  

Picking the youngest means that, as you say, predictability decreases in the
case where one buffer gets stuck for a very long time. This arguably shouldn't
happen generally, but provably does right now until Mesa gains the smarts to
trim the buffer queue. I can see how this would be provoked on a CPU-bound
system where we are doing direct scanout; by picking the youngest, we react to
this situation by generating more CPU load.

  

Picking the oldest means that the queue remains balanced, which does imply a
complexity increase in the case that the surface damage area changes from
frame to frame. I do not believe that this is a common case, and even if it
were, the downside of this is not as bad as the downside of picking the
youngest.

  

Cheers,

Daniel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161110/2995bc48/attachment.html>