On Thu, 10 Nov 2016 16:01:32 +0000 Daniel Stone <dani...@collabora.com> wrote:
> 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. Hi, a very good explanation. I wish it was reflected in the commit message. Thanks, pq
pgpgo_zvbSdEt.pgp
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
