Ideas on portable APIs to cheaply copy a GBM bo?

[Daniel Stone]

Hi Pekka,

On 12 October 2017 at 07:56, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Wed, 11 Oct 2017 09:01:30 -0500
> Matt Hoosier <matt.hoosier at gmail.com> wrote:
>> I'll have a look there. One thing that for simplicity I left out of
>> the original description above is that this custom Weston output has a
>> fast-path very similar to the normal DRM scanout optimizations. So if
>> that path gets hit, it's often the live DRM buffer supplied by the
>> client whose dmabuf fd we're using in the background processing. I'm
>> not sure that I can robustly assume that the clients support stacking
>> up arbitrarily deep numbers of renderbuffers. If all the buffers
>> getting chewed on were owned strictly inside the compositor, I think
>> that relying on 4-deep buffering in Mesa might be do-able. I'll have
>> to think about whether that makes sense to generalize to client
>> buffers as well.
>
> It has always been the intention that yes, also clients do need to
> allocate more buffers as they need. But, reality probably disagrees,
> since there has not been too much of actual need to use more than three
> buffers, so toolkit writers might assume there is a low limit to how
> many buffers there might ever be necessary. It is definitely worth to
> test though, and I would not preclude filing bugs against toolkits to
> raise their limits.
>
> I would be a little surprised if EGL GBM and Wayland platforms as
> implemented in Mesa would differ in their limits though, but that
> should be easy to fix.

If you look at dri2_egl_surface::color_buffers inside
src/egl/drivers/dri2/egl_dri2.h, you can see that it's 4 for both
platforms, and has been since 2013, when eglSwapInterval(0) became a
thing. There's some rationale, but it's essentially: one that you're
rendering into, one you've attached to the compositor, one the
compositor's attached to the kernel, and one that the compositor
hasn't yet released.

I can't speak for non-Mesa sources.

Cheers,
Daniel