Ideas on portable APIs to cheaply copy a GBM bo?

[Pekka Paalanen]

On Wed, 11 Oct 2017 09:01:30 -0500
Matt Hoosier <matt.hoosier at gmail.com> wrote:

> On Tue, Oct 10, 2017 at 11:53 AM, Daniel Stone <daniel at fooishbar.org> wrote:

> 
> >> Another option is to enforce a synchronous handshake between the
> >> Weston foreground loop and the compressor/transmit asynchronous code.
> >> The idea would be to (1) suck out the primary plane GBM bo's dmabuf,
> >> (2) wait for the async stuff to work and then signal the completion of
> >> its usage on the BO, and then (3) release the BO locked in the first
> >> step. This has some pretty bad stalling implications though -- the
> >> async code can at times take nearly a full frame to run. The spillover
> >> into the next vblank period would basically force this scheme to run
> >> at half the normal framerate even though better interleaved use of the
> >> hardware can do much better.  
> >
> > Well, when you say back/front ... it can be more than just two. By
> > default, Mesa's GBM implementation should quad-buffer if you sit on
> > unreleased buffers for long enough. Have you tried it out? That's
> > definitely what I'd recommend, anyway: all the other options are, as
> > you've noted, bad.  
> 
> 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.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171012/d55976f2/attachment.sig>