Wayland generic dmabuf protocol
robdclark at gmail.com
Thu Jun 12 07:19:13 PDT 2014
On Wed, Jun 11, 2014 at 2:26 AM, Thomas Hellstrom <thellstrom at vmware.com> wrote:
> On 06/09/2014 01:23 PM, Daniel Stone wrote:
>> On 9 June 2014 12:06, Pekka Paalanen <pekka.paalanen at collabora.co.uk
>> <mailto:pekka.paalanen at collabora.co.uk>> wrote:
>> On Mon, 9 Jun 2014 11:00:04 +0200
>> Benjamin Gaignard <benjamin.gaignard at linaro.org
>> <mailto:benjamin.gaignard at linaro.org>> wrote:
>> > One of the main comment on the latest patches was that wl_dmabuf use
>> > DRM for buffer allocation.
>> > This appear to be an issue since wayland doesn't want to rely on one
>> > specific framework (DRM, or V4L2) for buffer allocation, so we have
>> > start working on a "central dmabuf allocation" on kernel side. The
>> > goal is provide some as generic as possible to make it acceptable by
>> > wayland.
>> Why would Wayland need a central allocator for dmabuf?
>> I think you've just answered your own question further below:
>> > On my hardware the patches you have (+ this one on gstwaylandsink
>> > https://bugzilla.gnome.org/show_bug.cgi?id=711155
>> allow me to do zero
>> > copy between the hardware video decoder and the display engine. I
>> > don't have implemented GPU yet because my hardware is able to do
>> > compose few video overlays planes and it was enough for my tests.
>> What I have been thinking is, that the compositor must be able to use
>> the new wl_buffer and we need to guarantee that before-hand. If the
>> compositor fails to use a wl_buffer when the client has already
>> attached it to a wl_surface and it is time to repaint, it is too late
>> and the user will see a glitch. Recovering from that requires asking
>> the client to provide a new wl_buffer of a different kind, which might
>> take time. Or a very rude compositor would just send a protocol error,
>> and then we'd get bug reports like "the video player just disappears
>> when I try to play (and ps. I have an old kernel that doesn't support
>> importing whatever)".
>> I believe we must allow the compositor to test the wl_buffer before it
>> is usable for the client. That is the reason for the roundtrippy
>> of the below proposal.
>> A central allocator would solve these issues, by having everyone agree
>> on the restrictions upfront, instead of working out which of the media
>> decode engine, camera, GPU, or display controller is the lowest common
>> denominator, and forcing all allocations through there.
>> One such solution was discussed a while back WRT ION:
>> See the 'possible solutions' part for a way for people to agree on
>> restrictions wrt tiling, stride, contiguousness, etc.
> I think before deciding on something like this, one needs also to
> account for the virtual drivers like vmwgfx.
> Here, a dma-buf internally holds an opaque handle to an object on the
> host / hypervisor, and the actual memory buffer is only temporarily
> allocated for dma-buf operations that strictly need it. Not to hold the
> data while transferring it between devices or applications.
> Let's say you'd want to use a USB display controller in a virtual
> machine with the vmwgfx exported prime objects, for example. There's no
> common denominator. The vmwgfx driver would need to read the dma-buf
> data from the host object at sg-table export (dma-buf map) time.
> Whereas if you just want to share data between a wayland server and
> client, no pages are ever allocated and the only thing passed
> around is in effect the opaque handle to the host / hypervisor object.
> I'm currently having trouble seeing how a central allocator would be
> able to deal with this?
well, central standalone allocator device would need to know about all
possible devices. Works ok in a cell phone. I don't really see it
scaling well to desktop, so it isn't really an option.
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
More information about the wayland-devel