Hi, On Nov 10 2016, at 2:09 pm, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Wed, 9 Nov 2016 14:57:22 -0600 Derek Foreman <der...@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
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
