Ideas on portable APIs to cheaply copy a GBM bo?

[Matt Hoosier]

On Tue, Oct 10, 2017 at 11:53 AM, Daniel Stone <daniel at fooishbar.org> wrote:
> That more or less makes sense at the moment, though there has been
> quite a bit of work on less insane remoting within Weston. And then
> GNOME is using PipeWire for this. But anyway, you probably know this
> and it's not your immediate question.

I hadn't heard of PipeWire; thanks, but at least the project
description seems way more ambitious than my needs at the moment.

>> 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.

>
>> Does the readership here on wayland-devel know of any DRM-centric API
>> (I looked and nothing came to mind) for leveraging a basic cheap blit
>> from one DRM fb into another?
>
> In a lot of cores, you don't get particularly easy access to blit
> engines as they're more general-purpose these days. There also isn't a
> generalsed API at all, even for the more fixed-function hardware.


Thanks for the ideas -- they're appreciated.