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

[Pekka Paalanen]

On Thu, 10 Nov 2016 16:01:32 +0000
Daniel Stone <daniels at collabora.com> wrote:

> 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.

Hi,

a very good explanation. I wish it was reflected in the commit message.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161114/e739b904/attachment.sig>