Sharing meta-data between DMA-BUF exporter and importer

[Pekka Paalanen]

On Wed, 4 Jun 2014 17:07:01 +0200
Thierry Reding <thierry.reding at gmail.com> wrote:

> Hi,
> 
> I've recently added support for Tegra K1 to kmscube[0]. The changes add
> support for sharing buffers using DMA-BUF. On Tegra K1 the buffers are
> shared between the GK20A GPU (Nouveau) for rendering and Tegra DRM for
> display.
> 
> One of the commits[1] adds a Tegra-specific hook that sets the tiling
> parameters of the imported buffer. I've discussed this a bit with Rob on
> IRC and he asked me to raise the issue with a broader audience. Weston
> is eventually going to need something along the same lines. One idea was
> to implement something like that in gbm, though for it to be useful in
> the general case I think it would need to be based on a data structure
> that's hardware agnostic. The process how this would work is that the
> application could do something like this:
> 
> 	/*
> 	 * This should be able to represent all known tiling modes that
> 	 * could possibly be set on a buffer object and is just an
> 	 * example of how this could look like. There are possibly many
> 	 * different and better ways to do this.
> 	 */
> 	struct gbm_bo_tiling {
> 		enum gbo_bo_tiling_mode mode;
> 
> 		union {
> 			...
> 		};
> 	};
> 
> 	struct gbm_device *gpu, *display;
> 	struct gbm_bo_tiling tiling;
> 
> 	/* get tiling parameters from importer */
> 	err = gbm_bo_get_tiling(gpu, bo, &tiling);
> 	if (err < 0) {
> 		...
> 	}
> 
> 	fd = gbm_bo_export(gpu, bo);
> 	if (err < 0) {
> 		/* can't export DMA-BUF */
> 		...
> 	}
> 
> 	/* import bo */
> 	bo = gbm_bo_import(display, GBM_BO_IMPORT_DMA_BUF, (void *)fd, ...);
> 	if (!bo) {
> 		/* can't import DMA-BUF */
> 		...
> 	}
> 
> 	err = gbm_bo_set_tiling(display, bo, &tiling);
> 	if (err < 0) {
> 		/* tiling parameters not compatible with importer */
> 		...
> 	}
> 
> I guess optionally there could be some sort of negotiation between
> importer and exporter about what tiling parameters they support, but
> that can possibly be built on top of the above.

Hi,

from what I've seen flying past in IRC, the issue has so far been
ignored by allocating all exportable (or USE_SCANOUT?) buffers as
linear. </rumour>

Let's say you use this for negotiating a proper tiling format between
exporter and importer. I'm not sure, but I think the tiling format gets
decided on bo creation time. How would you ask for an alternative
tiling format in GBM?

Then thinking about how that would work over a protocol like Wayland; A
client is creating a buffer, and wants the compositor to present it,
putting it on a hardware overlay if possible, or even scanning it
out directly. We would like to know in advance what parameters are valid
to avoid a roundtrip, but that's a lesser issue for now. We would need
to be able to serialize the tiling definition to send it over the
connection, and somehow negotiate a tiling that satisfies both sides.

I'm not sure how feasible it would be for the compositor to tell the
client which device it is going to use, so that the client could
internally find a good tiling mode. It is also imaginable, that the
compositor could be using multiple devices, and needs have the tiling
fit for them all - or just fall back to requiring a tiling that works
for the one GPU it is using for compositing and exclude the use of
hardware overlays.

Or maybe it could be other way: the client telling the compositor which
device it wants to use to create buffer contents, and then the
compositor replies with a suitable tiling format.

What use cases would you like to cover? Only in-process negotiation
between two devices so a compositor can show on one device what it
renders on another, or also the display server vs. client negotiation?


Thanks,
pq

> I'm adding Christian Gmeiner since I'm told he'll be likely needing
> something similar for his work on etnaviv and it would be good to get a
> second opinion on this.
> 
> Thierry
> 
> [0]: https://gitorious.org/thierryreding/kmscube
> [1]: https://gitorious.org/thierryreding/kmscube/commit/b4d79d5c4e27b6d37234a137bdefc6ff517d6ea4