diff options
author | Robert Mader <robert.mader@collabora.com> | 2024-09-26 23:07:39 +0200 |
---|---|---|
committer | Kieran Bingham <kieran.bingham@ideasonboard.com> | 2024-09-27 16:40:15 +0100 |
commit | abe2ec64f9e4e97bbdfe3a50372611bd7b5315c2 (patch) | |
tree | 4ad34c713d45ef67e5695400cc1da946d55c7da0 /src/ipa/rkisp1/algorithms/dpf.h | |
parent | 6c0aefdaf92b62e77bdc3b8add2b8107e50a5544 (diff) |
pipeline: simple: Increase buffer count to four
Which is not only what many other pipeline handlers use, but also a good
lower limit when dealing with DRM and similar APIs. Even Mesas EGL and
Vulkan WSI implementations use for the reason outlined in mesa commit
992a2dbba80aba35efe83202e1013bd6143f0dba:
> When the compositor is directly scanning out from the application's buffer it
> may end up holding on to three buffers. These are the one that is is currently
> scanning out from, one that has been given to DRM as the next buffer to flip
> to, and one that has been attached and will be given to DRM as soon as the
> previous flip completes. When we attach a fourth buffer to the compositor it
> should replace that third buffer so we should get a release event immediately
> after that. This patch therefore also changes the number of buffer slots to 4
> so that we can accomodate that situation.
Given the popularity of this buffer number the bump should be unlikely
to cause problems. At the same time it may help with performance or
even work around glitches.
The previous number was introduced in commit
a8964c28c80fb520ee3c7b10143371081d41405a without mentioning a specific
reason against the change at hand.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Diffstat (limited to 'src/ipa/rkisp1/algorithms/dpf.h')
0 files changed, 0 insertions, 0 deletions