LCA14-417: mmap, allocators & sharing buffers - userland experience. Thu 6 March, 4:10pm, S.Semwal, B.Gaignard

Transcription

1 LCA14-417: mmap, allocators & sharing buffers - userland experience Thu 6 March, 4:10pm, S.Semwal, B.Gaignard

2 Agenda Discussion, not presentation :) Current state Your experiences? Idea of Central dmabuf allocator helpers Open forum

3 Discussion, not presentation :) Intentions of this session: Share the changes likely to happen as part of UMM initiative that would affect how userspace works with allocation and buffers Share idea of central buffer allocator helpers Understand from the audience if the steps make any sense to their experience domain; if not, what are the gaps. Try to find ways to fulfill the gaps; or at least document them clearly

4 Pre-UMM State Pre-UMM days, a sample userspace application, eg. one working with a camera with v4l2 interface and a DRM based display, would need to: know about the v4l2 and drm buffer structs, know who (or decide) will allocate, and sometimes have that fixed for each platform, have some middleware component (like GStreamer) which could handle conversions from one type of buffers to the other, in some cases, copy over data across buffers.

5 GStreamer 0.10 without dma-buf buffer with v4l2 metadata (index, userptr ) Capture plugin: v4l2src Display plugin: ximagesink parameters conversion from v4l2 metadata to X metadata, may require copying buffer data queue/de queue mmaped or userptr buffers v4l2 driver buffer send through Xserver DRM driver

6 Your experiences?

7 Changes post UMM initiative dma-buf framework added to make sharing buffers across frameworks easier; no longer need to know all the buffer structs, if all participating subsystems use the dma-buf API Also allows to defer allocation of backing storage till first map_attachment() request from one of the attached devices There is interest in having central dmabuf allocator helpers These can help in the userspace not having to worry about which device s allocator function to invoke; Userspace might be able to just: use a generic dma-buf exporter device, have each participating importer share their constraints during attach(), have the exporter device use these constraints to decide on where to allocate from.

8 dma-buf usage model dmabuf usage model: dma_buf_get() dma_buf_attach() dma_buf_map_attachment() dma_buf_unmap_attachment() dma_buf_detach() dma_buf_put() dmabuf exporter doesn t necessarily allocate backing buffer until map_attachment() time.

9 Current State With dma-buf, now the same sample userspace application would need to: still know about the v4l2 and drm buffer formats, still know who will allocate, and sometimes have that fixed for each platform, the allocator will also be the exporter of dma-buf, and the other users of the buffers can just be attached to the same exported buffer, and use the same underlying memory no copying needed! have some middleware component (like GStreamer) which would not need to do any conversions across types of buffers for zero-copy purposes. (middleware would still be needed for other uses though cap negotiation etc).

10 Idea of Central dma-buf allocator helpers Create a set of constraint aware dma-buf allocation helper functions On dma_buf_attach(), store compatible constraints flags for that device in dma-buf Provide helper functions that will look at constraints flags on dma-buf and allocate memory from the compatible heap userspace could be just one central dma-buf allocator, which could be supplied with platform-specific heaps

11 Proposed Changes in dma-buf usage model New functionality in the usage sequence: dma_buf_get() - importer to set constraints in dev->dma_parms>access_constraints_mask dma_buf_attach() - adds constraint to dma-buf; will return error if new device attachment doesn t satisfy existing constraints dma_buf_map_attachment() - exporter looks at constraint mask, and (optionally) uses allocation helpers to allocate dma_buf_unmap_attachment() dma_buf_detach() - re-calculates dma-buf s constraint mask dma_buf_put()

12 Gstreamer 1.X with dma-buf buffer pool: negotiated and shared by the both plugins dma-buf Capture plugin: v4l2src Display plugin: waylandsink wayland protocol wayland server create buffer: return fd queue/dequeue dma-buf buffer central dma-buf allocator v4l2 driver dma-buf fd imported by prime DRM driver

13 Open Forum

14 More about Linaro Connect: More about Linaro: More about Linaro engineering: Linaro members: